Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Not compatible with native node require and webpack #141

Open
1 of 10 tasks
cdebost opened this issue Jan 10, 2019 · 0 comments
Open
1 of 10 tasks

Not compatible with native node require and webpack #141

cdebost opened this issue Jan 10, 2019 · 0 comments

Comments

@cdebost
Copy link
Collaborator

cdebost commented Jan 10, 2019

mr supports some features that a native node require or webpack do not. In order to eventually drop mr from montage, these features should be phased out.

  • Fix module-resolution spec with bug #118 Should not expose dependencies package's require  #15 mr resolves modules differently from node. It allows loading modules relative to the package, without a relative path, e.g. require("core/foo") instead of require("../core/foo"). In Node, requires to local modules must start with ./ or ../. This difference also allows loading transitive dependencies, e.g. require("montage/collections"), which is poor practice. To minimize the impact on montage applications, we could enhance the montage deserializer to automatically convert prototype/object paths that start with ui/core/data/logic to be relative, possibly with a deprecation warning.
  • mr's ReelLoader, which silently loads require("ui/foo.reel") at ui/foo.reel/foo.js, is non-standard. ReelLoader should be moved to montage proper and should log a deprecation warning, eventually requiring that components are required with the correct standard path. To avoid impacting montage serialization templates too much, the deserializer can be enhanced to interpret a prototype/object of ui/foo.reel as ui/foo.reel/foo.js.
  • mappings on package.json is non-standard. This is primarily used in .info directories to avoid having many duplicate copies of montage or the parent package. This kind of thing is exactly what npm 3+'s de-duping accomplishes.
  • overlay on package.json is non-standard. I don't currently know of any projects where we actually need to use overlay. The alternative is to have a single entry script that discovers the environment itself, which doesn't feel like a huge tradeoff in order to remain standard-compliant.
  • browser on package.json is non-standard. It's a browserify-specific feature and mr automatically converts it to an overlay.
  • directories on package.json is non-standard. It allows the user to override where mr looks for modules and unknown packages. It was actually removed from mr and montage a long time ago, but mop kept handling it. Removed handling from mop, and removed mr doc references.
  • production on package.json is non-standard, but package-lock.json does have a dev property which seems to have the same purpose. I think this is only necessary due to a flaw in mop, which includes all node_modules to the final build. mop should not include devDependencies of a package in the build.
  • redirects on package.json is non-standard. The only use of this I know of is montage itself, which redirects the main package's exports to montage/core/core, so that we can do <script src="./node_modules/montage/montage.js"> to bootstrap and require("montage") == require("montage/core/core").
  • useScriptInjection on package.json is non-standard. Not sure about this one, when is loading via script preferable to loading via XHR?
  • extraDependencies

If any of these are inaccurate, let me know or make an edit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant