Lock all versions

[eric-burel]

Hin In light of recent issues I encountered due to the upgrade to React 16 (#1815, #1812) in the 1.8.3, I think it would be good to lock all packages versions, in the starter and in the core repo using the @= syntax.

This way we won't ever suffer for breaking changes in minor versions, which definitely do happen, sooner or later, in a package or another (I am worried that npm --save still creates a ^1.x.x by default...).

Better, we would truly enjoy the latest Vulcan update, but only when we are ready :)

Also without lock it is very hard to rollback to a previous versions, because subpackages will themselves load the last version.

[SachaG]

Any arguments against doing this? I don't know enough about package management to have a strong opinion so if nobody disagrees I'd accept a PR.

[eric-burel]

To be fair I don't know much about how Meteor handles package either, I would be glad to have some feedback on this.

[justinr1234]

Seems like a good idea to me

[MathiasKandelborg]

Would this be a good time to talk about using npm as a package manager?

I will happily make arguments, do initial work and give a proper introduction to releasing to npm.

To finish my suggestion: Using npm would be a lot easier and actually make sense. In that, we would reach a broader audience and lock into an ecosystem that's maintained. I'll also go the extra mile and state that it's endorsed by thousands if not millions across the world.

[eric-burel]

Good idea but don't how do you handle the packages loading in Meteor ? Because Meteor rely on a specific folder structure (lib, client, server), so just importing a npm "vulcan-core" for example won't load the files of the vulcan-core as expected. An idea could be to create some simlink from node_modules in the local packages folder?

Maybe I missed something about this, since the Meteor team seems to be working on a "de-atmospherization" of their package management ?

[justinr1234]

Swapping to npm packages is a large undertaking. If someone has the knowledge to do so, go for it. But it is a huge undertaking and would be a massive breaking change.

[MathiasKandelborg]

@justinr1234 I totally agree and am aware of this. I'm standing by everything I said. The benefits are enormous compared to not doing it.

@eric-burel I have read somewhere that they would be working on a "de-atmospherization" at some point - hence my suggestion.

My biggest concerns are reaching a broader audience and in the meantime upgrade how Vulcan actually works. I would like to see some of the Vulcan packages be something you could use in any JS app, not just in the Meteor eco-system.

I know this subject might be very sensitive. But someone has to bring it up. I would like a clear answer/vote on where Vulcan is headed as a whole. I'm trying to get a grasp of the next year, three years etc.

As said. I'd like to make arguments. (these will take some time and will be constructed very thoughtfully, based on hours of research)

[eric-burel]

Just so we settle this before, since you are here @MathiasKandelborg and @justinr1234, do you have an opinion on locking Meteor and Vulcan packages versions? Could it raise unexpected issues in your opinion (complexify updates for example etc.) ?

Edit: also a good starting point would be to check out what's ongoing with Meteor on this, since the npm/atmosphere issue is far beyond Vulcan scope.

[MathiasKandelborg]

EDIT: Locking versions is good, I need to be explicit about that. This is exactly what I'm on about. I don't even know how you would achieve this with Meteor.

There's so much 'magic' going on with packages and I won't spend hours upon hours on a whole package manager system in which I can't do things like I would in any other app I'll ever develop. I'm clearly not a Meteor fanboy, which is not the point here.

The point I want to get across is, that I want everyone to be able to adapt Vulcan with ease, which is not currently possible without first getting to know Meteor, the Atmosphere system, rely on a black box and then learn Vulcan.

I have no idea how you would lock versions with Meteor. It's really really easy with npm.

[justinr1234]

• locking versions is good
• fine with moving to lerna packages from meteor,, assuming we also swap the accounts off meteor

[MathiasKandelborg]

@SachaG Thoughts? Besides wanting a PR regarding being able to lock versions.

[SachaG]

Swapping to npm packages is a large undertaking. If someone has the knowledge to do so, go for it. But it is a huge undertaking and would be a massive breaking change.

Basically this. For starters I don't think NPM makes it as easy as Meteor does to specify what part of a package's code runs on the client, server, or both.

Overall I agree that Meteor is probably a barrier to adoption for Vulcan, but looking at it another way I'd hope that Vulcan provides enough value to convince people to use it despite Meteor.

[MathiasKandelborg]

Completely understandable. Thanks for giving your two cents. There's this though (second paragraph in bold) I'm just leaving this statement here, as I haven't given up entirely: Using a bundler like Parcel or Webpack, to bundle the exact files you need for either Client, Server or both - then using babel to make sure code runs where you want. Is not hard at all. It was 6 years ago.

[SachaG]

I'm sure it's doable, I'm just not familiar with any of those tools personally.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[eric-burel]

I've locked versions in the vulcan:core/package.js file. This should prevent mismatch between versions for older app (the core often tries to load a more recent version of vulcan:lib). This may not be enough but let's test that.

Also npm dependencies that tends to break often even with patches (looking at you, Apollo) are locked using --save-exact.