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

JS Distribution Strategy #2428

Closed
robwormald opened this issue Jun 9, 2015 · 5 comments
Closed

JS Distribution Strategy #2428

robwormald opened this issue Jun 9, 2015 · 5 comments
Assignees

Comments

@robwormald
Copy link
Contributor

Happy to tackle some of these, wanted to list them in case they're already on the roadmap.

  • we should stop using the *.es6 extension - it makes it quite difficult to work with the ES6 source.
  • ES6 consumers are likely going to want to bundle themselves, vs using a pre-built bundle.
  • ES6 consumers are likely going to want to consume ES6 (or TS) source, vs commonJS (which has already caused a few issues)
  • There are a bunch of extraneous dependencies listed in the package.json currently (vs being in devDependencies) so installing via jspm adds a huge amount of unnecessary stuff.

JSPM / SystemJS now support Typescript (including in-browser transpilation), so it might be a good time to look at getting set up in the registry properly. Doing jspm install npm:angular2 again requires you to manually override to be able to access the ES6 source. We can easily add angular2 to the registry, and add the ovveride there (to point to es6/dev or es6/prod), but it would be nice if it was set up correctly in the repo (and had .js file extensions)

Also note that the Loader spec is changing, and the latest version of SystemJS (0.17+) has a number of breaking changes that may bite us if they're not accounted for: whatwg/loader#52

@robwormald
Copy link
Contributor Author

I'm tracking the registry stuff over here, jspm/registry#385, mostly blocked until we have .js extensions. Note that consuming commonJS works, but when there's a problem with the build (like there is now), we're sort of stuck until the next bump.

@robwormald
Copy link
Contributor Author

example of the kind of overrides needed to use it - not a big issue, but just one more bit of friction to get up and running. https://github.com/robwormald/ng2-jspm-seed/blob/master/jspm.conf.js#L34-L41

@rkirov
Copy link
Contributor

rkirov commented Jun 9, 2015

@robwormald renaming es6 to js and cleaning up our package.json should happen and are non-controversial (or least this is the place for someone to make them controversial). I will open separate issues for those.

We agree that the bundle is not the way to go for es6 or ts consumers, thats why we publish es6, and ts sources to npm on top of the es5 (commonjs). I am ok with adding jspm info to our package.json as long as it has no maintenance cost. Npm would still be the preferred method for delivering and consuming Angular2.

@rkirov
Copy link
Contributor

rkirov commented Jun 9, 2015

Superceded by #2447 and #2448

@rkirov rkirov closed this as completed Jun 9, 2015
@angular-automatic-lock-bot
Copy link

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Sep 6, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants