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

[1.6] Published package with build plugin does not work anymore on any pre 1.6 version #9308

Closed
wojtkowiak opened this Issue Nov 6, 2017 · 3 comments

Comments

Projects
None yet
3 participants
@wojtkowiak
Contributor

wojtkowiak commented Nov 6, 2017

After publishing omega:meteor-desktop-bundler with 1.6 I got when using the plugin with 1.5.2.2

=> App running at: http://localhost:3000/
   Type Control-C twice to stop.

=> Errors prevented startup:

   While loading plugin `meteor-desktop-bundler` from package `omega:meteor-desktop-bundler`:
   vm.js:24:10: Block-scoped declarations (let, const, function, class) not yet supported outside strict mode
   at Object.exports.createScript (vm.js:24:10)

Similarly I tried to use meteor-css-modules@2.8.0 which was published with 1.6 and could not because of similar problem.
nathantreid/meteor-css-modules#107

It seems that the build plugins were not transpiled anymore even though in use they depend on old ecmascript version. I can guess that it is because server side is no longer transpiled (cause of Node
8). Maybe I got this part wrong but I was always expecting the Package.use section as the way to enforce compatibility with older versions

After publishing with 1.5 everything works as expected.

@benjamn

This comment has been minimized.

Show comment
Hide comment
@benjamn

benjamn Nov 6, 2017

Member

An api.use version constraint restricts the major version of the package, but otherwise just sets a lower bound on the version of the package that can be used. For example, since ecmascript is still at major version 0, a constraint like ecmascript@0.8.0 is totally compatible with ecmascript@0.9.0 (the latest version), since the major version is the same, and 9 ≥ 8.

In order to maintain compatibility with Meteor 1.5 apps when publishing your package, you can specify a release version for the meteor publish command:

meteor --release 1.5.3 publish

If you want to take advantage of Meteor 1.6, I would recommend creating a new branch where you bump your package's minor or major version, then publish using Meteor 1.6 from that branch, and publish using Meteor 1.5 from the original branch. The version bump is important so that you can continue publishing patch updates for Meteor 1.5.

Member

benjamn commented Nov 6, 2017

An api.use version constraint restricts the major version of the package, but otherwise just sets a lower bound on the version of the package that can be used. For example, since ecmascript is still at major version 0, a constraint like ecmascript@0.8.0 is totally compatible with ecmascript@0.9.0 (the latest version), since the major version is the same, and 9 ≥ 8.

In order to maintain compatibility with Meteor 1.5 apps when publishing your package, you can specify a release version for the meteor publish command:

meteor --release 1.5.3 publish

If you want to take advantage of Meteor 1.6, I would recommend creating a new branch where you bump your package's minor or major version, then publish using Meteor 1.6 from that branch, and publish using Meteor 1.5 from the original branch. The version bump is important so that you can continue publishing patch updates for Meteor 1.5.

@wojtkowiak

This comment has been minimized.

Show comment
Hide comment
@wojtkowiak

wojtkowiak Nov 7, 2017

Contributor

@benjamn thank you very much for your time explaining and for the idea how to approach this.
I think it's understandable and now that I fully understand this I can go on.
It might be worthy however to always include a note for the package maintainers in the history.md to warn about it as I've already found 3 authors who published with 1.6 and were not aware that they unintentionally dropped support for 1.4/1.5.
Thanks once again for your time!

Contributor

wojtkowiak commented Nov 7, 2017

@benjamn thank you very much for your time explaining and for the idea how to approach this.
I think it's understandable and now that I fully understand this I can go on.
It might be worthy however to always include a note for the package maintainers in the history.md to warn about it as I've already found 3 authors who published with 1.6 and were not aware that they unintentionally dropped support for 1.4/1.5.
Thanks once again for your time!

@hwillson

This comment has been minimized.

Show comment
Hide comment
@hwillson

hwillson Nov 7, 2017

Member

Great idea @wojtkowiak - I've added a quick mention of this in #9314. Thanks!

Member

hwillson commented Nov 7, 2017

Great idea @wojtkowiak - I've added a quick mention of this in #9314. Thanks!

@benjamn benjamn closed this in #9314 Nov 7, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment