You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 #118Should not expose dependencies package's require #15mr 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.
The text was updated successfully, but these errors were encountered:
mr
supports some features that a native noderequire
orwebpack
do not. In order to eventually dropmr
from montage, these features should be phased out.mr
resolves modules differently from node. It allows loading modules relative to the package, without a relative path, e.g.require("core/foo")
instead ofrequire("../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 convertprototype
/object
paths that start withui
/core
/data
/logic
to be relative, possibly with a deprecation warning.mr
'sReelLoader
, which silently loadsrequire("ui/foo.reel")
atui/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 aprototype
/object
ofui/foo.reel
asui/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 useoverlay
. 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 andmr
automatically converts it to an overlay.directories
on package.json is non-standard.It allows the user to override whereIt was actually removed frommr
looks for modules and unknown packages.mr
andmontage
a long time ago, butmop
kept handling it. Removed handling frommop
, and removedmr
doc references.production
on package.json is non-standard, butpackage-lock.json
does have adev
property which seems to have the same purpose. I think this is only necessary due to a flaw inmop
, which includes all node_modules to the final build.mop
should not includedevDependencies
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 tomontage/core/core
, so that we can do<script src="./node_modules/montage/montage.js">
to bootstrap andrequire("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.
The text was updated successfully, but these errors were encountered: