oriservice-windows-arm64 - npm Package Compare versions

Comparing version 0.0.0-pre-alpha.2-0d0983f to 0.0.0-pre-alpha.2-0de62bc

package.json

		{
		"name": "oriservice-windows-arm64",
		"license": "MIT",
		"version": "0.0.0-pre-alpha.2-0d0983f",
		"version": "0.0.0-pre-alpha.2-0de62bc",
		"repository": {
		@@ -6,0 +6,0 @@ "url": "https://github.com/microsoft/ori"

README.md

		@@ -8,42 +8,28 @@ # ori
		```
		ori -h
		ori dev --help
		Runs the oribuild development loop.

		-blockFollowUp
		Wait for an initial build before running non-build tasks (implied by -traceInitialBuild)
		-config string
		Path to ori.json (default "./ori.json")
		-cpuprofile string
		Generate a cpu profile at the given path
		-entry string
		Use a given entry or entry group (from the values specified in ori.json)
		-gitRef string
		initial set of changed files to use when starting the typescript process (default "HEAD")
		-initialOnly
		Validate the initial build can complete, and exit with an error if it had issues
		-logLevel string
		log level (error\|warning\|info\|verbose\|debug)
		-logTs
		log typescript output to stdio
		-noTui
		Disable the tui and print everything to stdio
		-nosplit
		Disable codesplitting. Allows for bundling without esm.
		-port int
		Port to run the http server on (default 3000)
		-snoop
		log imports to a snoop.json file, which can be analyzed to determine why a module is included in a build.
		-sourcemap string
		Generate sourcemaps (one of 'none', 'inline', 'external', 'linked', 'inline-and-external') (default "none")
		-strategy string
		Build Strategy (default "vendor")
		-trace string
		Generate an event trace at the given path
		-traceIncrementalBuilds
		Collect a pprof trace of each incremental build
		-traceInitialBuild
		Collect a pprof trace of the initial build
		-version
		Print the version and exit
		-write
		Write to disk
		Usage:
		ori dev [flags]

		Flags:
		--blockFollowUp Wait for an initial build before running non-build tasks (implied by --traceInitialBuild)
		--config string Path to ori.json (default "./ori.json")
		--cpuprofile string Generate a cpu profile at the given path
		--entry string Use a given entry or entry group (from the values specified in ori.json)
		--gitRef string initial set of changed files to use when starting the typescript process (default "HEAD")
		-h, --help help for dev
		--initialOnly Validate the initial build can complete, and exit with an error if it had issues
		--logLevel string log level (error\|warning\|info\|verbose\|debug)
		--logTs log typescript output to stdio
		--noTui Disable the tui and print everything to stdio
		--nosplit Disable codesplitting. Allows for bundling without esm.
		--port int Port to run the http server on (default 3000)
		--snoop log imports to a snoop.json file, which can be analyzed to determine why a module is included in a build.
		--sourcemap string Generate sourcemaps (one of 'none', 'inline', 'external', 'linked', 'inline-and-external') (default "none")
		--strategy string Build Strategy
		--trace string Generate an event trace at the given path
		--traceIncrementalBuilds Collect a pprof trace of each incremental build
		--traceInitialBuild Collect a pprof trace of the initial build
		--write Write build outputs to disk in addition to serving them from memory
		```
		@@ -113,3 +99,3 @@

		Rather than alwasy running a single esbuild build, it is sometimes more performant
		Rather than always running a single esbuild build, it is sometimes more performant
		or practical to run multiple separate builds. The different ways of coordinating and
		@@ -126,3 +112,3 @@ connecting these separate builds are called "build strategies".
		This build strategy scans your repository for information about external dependencies on startup,
		and uses that information to build all of your external dependenices as a separate build.
		and uses that information to build all of your external dependencies as a separate build.

		@@ -221,15 +207,15 @@ This tends to speed up interactive iterative builds, because it cuts out the dependencies from

		# Build an entry named "OWA Mail" from the entrypoints map, with codesplitting
		# Build an entry named "OWA Mail" from the entry points map, with code-splitting
		# Note that this has to be loaded with a script type="module" entrypoint,
		# since esbuild codesplitting forces esm modules
		# since esbuild code-splitting forces esm modules
		go run . -config=../ori.json -entry="OWA Mail" -split

		# Generate a cpu profile for initial and incrmental builds (the traces directory must already exist)
		# Generate a cpu profile for initial and incremental builds (the traces directory must already exist)
		go run . -config=../ori.json -entry="OWA Mail" -traceInitialBuild -traceIncrementalBuilds -cpuprofile=traces/cpu.pprof

		# Analyse cpu profiles (constains overview of CPU time)
		# Analyze cpu profiles (contains overview of CPU time)
		go tool pprof -http=localhost:8080 traces/cpu.pprof.initial*
		go tool pprof -http=localhost:8080 traces/cpu.pprof.incremental*

		# Analyse traces
		# Analyze traces
		go tool trace traces/trace.out.*
		@@ -259,3 +245,3 @@

		For now, `ori` will remain extremly opinionared on what the monorepo shape must look like. As much as possible, we want to prefer convention over configuration.
		For now, `ori` will remain extremely opinionated on what the monorepo shape must look like. As much as possible, we want to prefer convention over configuration.

		@@ -262,0 +248,0 @@ In the same vein, rather than implementing plugins or encouraging people to fork and make their own custom builds of `ori`, new functionality will be added to the same `ori` binaries as needed.

NOTICE

Sorry, the diff of this file is not supported yet

oriservice-windows-arm64 - npm Package Compare versions

Improved metrics

Worsened metrics