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

Update package.json #11

Closed
wants to merge 1 commit into from
Closed

Update package.json #11

wants to merge 1 commit into from

Conversation

AbhiAgarwal
Copy link
Contributor

When you do an npm install with a --production flag it will not install babel.

In json-api/src/adapters/Mongoose/MongooseAdapter there's a line of code where it states import polyfill from "babel/polyfill";. This basically means that with or without a production flag babel needs to be imported.

This pull request is just moving it from the devDependencies to dependencies in general. When your default NODE_ENV is set to production then you NPM will automatically only install the dependencies and this will become an issue.

ethanresnick added a commit that referenced this pull request Aug 7, 2015
Basically, here’s what’s going on. Babel has a transformer, called
runtime, that can turn ES6 code like `new Promise()` into `new
core.Promise()`, where `core.Promise` is a polypill. But, that runtime
transformer (which I was already using), can’t polyfill some ES6 code
(e.g. `var it = "test"; it.startsWith("t");`) because it doesn't know,
e.g., that the `it` in `it.startsWith` is a string, so it doesn't know
that you're looking for `String.prototype.startsWith`. The solution to
this is to require the babel polypill, which modifies the global
`String.prototype` directly. That's what I was doing before this
commit, except that it also causes a problem: any dependents of this
library also get their globals changed.

Now, maybe that should usually be ok in practice—since most of the
polyfills match the ES6+ specs—but, of course, there's a possibility of
a polyfill having a bug, or two polyfills doing something different in
an unpolyfillable case. So, clobbering the dependent's globals is still
a bad idea. And, with this in mind, Babel actually throws an error if
the dependent tries to load babel/polyfill for a second time…so just
transparently modifying the globals and bearing the risk isn't possible
even if it's what we wanted to do.

So, this commit removes the polyfill's require, which then allows me to
move babel to a devDependency (without reopening #11, which was based
on the polyfill line). This means no using the ES6/7 `Array.prototype`
and `String.prototype` methods, but, oh well. It looks like I’d removed
all uses of them earlier anyway in preparation for this change.

Should close #47
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

Successfully merging this pull request may close these issues.

None yet

1 participant