merge V2 #130
Open
merge V2 #130
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
⚠️ 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.
Inherited by dependee packages.
Previously, a package with a "main" property that started with "./" would be linked incorrectly.
Instead of allocating a require function for every call, only create the closure if it’s needed.
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.
Since it just makes the application heavier at run time. I did have delusions about retaining it and scraping the text for debug purposes, but those illusions can be restored some other day.
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.
These features previously did not compose. Now, compilers and redirects are captured from the configuration after overlays have been applied.
The setimmediate package has a setImmediate.js main module, so we have to take care not to throw a warning about inconsistent module identifiers.
This has the happy side-benefit of increasing support for packages designed for Browserify, since the `browser` field gets converted to one or more `redirects`.
Existing packages in Node.js/npm ecosystem use a "directories" property to indicate that modules are in the "lib" directory, but Node.js does not read this configuration, so the user still has to include "lib" in module identifiers. This is not according to spec, but the behavior of ignoring the "directories" property has become a de-facto spec and these packages will not load with Mr if we persist in reading `directories.lib`. Also, there's no point in fighting the `node_modules` dependency packages directory configuration any longer. I have lost that fight.
⚠️ 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.
Instead of allocating a require function for every call, only create the closure if it’s needed.
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.
Since it just makes the application heavier at run time. I did have delusions about retaining it and scraping the text for debug purposes, but those illusions can be restored some other day.
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.
These features previously did not compose. Now, compilers and redirects are captured from the configuration after overlays have been applied.
This has the happy side-benefit of increasing support for packages designed for Browserify, since the `browser` field gets converted to one or more `redirects`.
Inherited by dependee packages.
And a comment or two
- Adds support for `preprocessorPackage`, which will be used for
optimizers (mandatory) and translators (optional), to avoid
entraining these dependencies in build products and to permit them
to use Node.js overlays instead of browser overlays during the
optimization process.
- Reworks the flow of the loader:
- translate
- analyze dependencies
- optimize
- compile
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.
Avoid changes due to random variations in load order.
With other related projects.
These files all came from pre-Motorola CommonJS test scaffolds.
Now applies to all but explicitly ignored files.
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
Contributors, license, repository
There be dragons.
Synchronize dependencies
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
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.
No description provided.