Build boot.js script using a build script #144
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
cdebost
force-pushed
the
feature/build
branch
5 times, most recently
from
d95a77f
to
140a764
Compare
⚠️ This includes backward incompatible changes that impact Montage and Mop. Changes to those packages in the corresponding `build` branch must be coordinated and released in a future, backward-incompatible release. Some care will be needed to ensure that `mop` in particular depends on compatible versions of `mr` and `montage`. This introduces a program, `mrs`, that can create stand-alone scripts from modules that only need the ability to produce and consume CommonJS modules with `require` and `exports` or `module.exports`, and depend only on a static working set. The resulting script has very little overhead and is based on the build products of Browserify. `mrs` is sufficient to build `mr/boot.js` (previously `bootstrap.js`)from the CommonJS modules in the `boot` directory. Run `npm run build`to produce a new revision of `boot.js` and `boot/preload-boilerplate.js`. This aleviates the need to perform script injection in the bootstrapping process, at the expense of introducing a build step for the bootstrapper. This change also allows a greater level of code reuse between Mr and Montage in their bootstrapping processes. This also obviates the need to embed UMD boilerplate in these modules, since they will always be used as CommonJS modules, either as sources for the build or as instruments of Node.js. Since `mrs` embeds the entirety of `boot.js`'s dependencies, it is no longer necessary to use a subrepository for these dependencies and no longer necessary to use hard-coded relative locations for these dependencies in `package.json`. These dependencies may now be installed by NPM and the maintainers of Mr and its dependencies no longer need to coordinate or hard-code their dependency trees. This is important because Q will soon be breaking up into smaller modules and packages. The `mini-url` module may now be a CommonJS module shared by Montage and Mr. Within Montage and Mr, it may be required by the name `url`. A mapping in `package.json` directs the module loader to use `mini-url.js` instead. On the Node.js side, where `mini-url.js` would not work, we fall back to Node.js's `url` module, which has an API that is a strict super-set of `mini-url.js`'s. Invert package nesting in browser boot: Previously, the root package was the module loader itself. Now, to match what is likely in practice, the application loads first, then the module loader, then promises.
If you can't beat 'em, join 'em. Also, some Node.js/npm packages depend on this and we would like them to work without modification, even if they're using bad nonstandard variable names that shouldn't have been made in the first place.
Previously, each module descriptor shared the root package object. This made identity checks on the package object possible for test for package equivalence, but `require.location` is a better practice anyway. The advantage of this new approach is that `module.require` is the same as `require` and can be used to resolve module ids releative to the module.
cdebost
force-pushed
the
feature/build
branch
from
140a764
to
18f34b0
Compare
Restructured the module names to fit the Browserify model. The former `require.js` has been renamed `common.js` which is augmented by both the Node.js and browser adaptors. Loading `mr` or `mr/require` will give you the interface appropriate for Node.js or the browser. The Node.js interface stands in `require.js` but is redirected to `browser.js` for client-side use. The tests now run with Jasminum in Node.js and in the browser. Phandom needs further study. However, there is a new Mr Jasminum boot script that can run arbitrary Jasminum test modules in the same way Mr boots normal CommonJS modules. Jasmine and its now unnecessary promise awareness shim have been scuttled. The boilerplate for bootstrapping has been extended to expose `module.bundle` to make it easy to inject already loaded or instantiated modules from the bootstrapping process into the run-time. This may or may not be desirable if the boot process use different, static versions of those modules. In production, they should be consolidated.
Implement Mr Phantom
- Missing preload module. - Incorrect require id for preload. - Script name not explicit in params reader.
The whole URL is cumbersome. Just use package name and module identifier. Take care to ensure that the display name is a valid JavaScript identifier, particularly if the package name starts with a number.
To break long line
By upgrading to latest Jasminum and accounting for the cyclic dependency of Jasminum's PhantomJS runner upon Mr.
Addresses problems with finding "mr", just as "q", when they are dependencies of the application package.
And use strict mode for builder
cdebost
force-pushed
the
feature/build
branch
from
18f34b0
to
2608649
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a recovery of #43, which is part of the #130 architecture overhaul, and parts of #130 which improved on #43. I rebased it on top of master as best I could so we can review it and see if it's worth applying. The changes have been discussed and reviewed at length in #43.
The original description is below:
buildbranch must be coordinated and released in a future, backward-incompatible release. Some care will be needed to ensure thatmopin particular depends on compatible versions ofmrandmontage.This introduces a program,
mrs, that can create stand-alone scripts from modules that only need the ability to produce and consume CommonJS modules withrequireandexportsormodule.exports, and depend only on a static working set. The resulting script has very little overhead and is based on the build products of Browserify.mrsis sufficient to buildmr/boot.js(previouslybootstrap.js)from the CommonJS modules in thebootdirectory. Runnpm run buildto produce a new revision ofboot.jsandboot/preload-boilerplate.js.This aleviates the need to perform script injection in the bootstrapping process, at the expense of introducing a build step for the bootstrapper. This change also allows a greater level of code reuse between Mr and Montage in their bootstrapping processes. This also obviates the need to embed UMD boilerplate in these modules, since they will always be used as CommonJS modules, either as sources for the build or as instruments of Node.js.
Since
mrsembeds the entirety ofboot.js's dependencies, it is no longer necessary to use a subrepository for these dependencies and no longer necessary to use hard-coded relative locations for these dependencies inpackage.json. These dependencies may now be installed by NPM and the maintainers of Mr and its dependencies no longer need to coordinate or hard-code their dependency trees. This is important because Q will soon be breaking up into smaller modules and packages.The
mini-urlmodule may now be a CommonJS module shared by Montage and Mr. Within Montage and Mr, it may be required by the nameurl. A mapping inpackage.jsondirects the module loader to usemini-url.jsinstead. On the Node.js side, wheremini-url.jswould not work, we fall back to Node.js'surlmodule, which has an API that is a strict super-set ofmini-url.js's.Invert package nesting in browser boot: Previously, the root package was the module loader itself. Now, to match what is likely in practice, the application loads first, then the module loader, then promises.