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

8.1. Site Packages should not be Browser specific (or even called site-packages just packages) #14

Open
johnjbarton opened this issue Feb 6, 2015 · 1 comment
Labels
Milestone

Comments

@johnjbarton
Copy link

This feature maps package names to root paths for resolving modules. Nothing about this functionality is specific to Browsers.

Developers want to be able to write source code that uses packages then import that code into any JS environment, whether it is browser, node, or future runtimes. Package name mapping separates the specification of the module-in-the-package from the specification of the path-to-the-package. The latter then can be configured when the packages are combined into an application.

In other words, developers need this feature to be independent of the runtime. No technical issue that I know about prevents such use. Really if you look at the API is just a Loader-blessed dictionary. Nothing about browsers involved.

@caridy
Copy link
Contributor

caridy commented Aug 21, 2015

We have a base loader, a default browser loader spec, and in the near future, a default node loader spec as well. SitePackage was deferred to stage 3 https://github.com/whatwg/loader/blob/master/roadmap.md#stage-3-conveniences, and #65 removes it from the spec, we will get back to it at some point. Let's keep this issue open for now.

@caridy caridy added this to the Milestone 3 milestone Apr 23, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

2 participants