search

analogjs / analog

The fullstack meta-framework for Angular. Powered by Vite and Nitro
https://analogjs.org
MIT License
2.57k stars 245 forks source link

[FEAT]: Update create-analog template application to latest dependencies #44

Closed brandonroberts closed 2 years ago

brandonroberts commented 2 years ago

The package.json needs updating here https://github.com/analogjs/analog/blob/main/packages/create-analog/template-angular-v14/package.json#L34-L35

Vite ^3.0.4 Vitest ^0.21.0

Yberion commented 2 years ago

Hello,

Can I take this one ?

Why not vite ^3.0.8 and vitest ^0.22.1?

May I suggest updating other packages of the template ?

tslib ^2.4.0 zone.js ~0.11.8 typescript ~4.7.4

brandonroberts commented 2 years ago

Sure. Updating those also is fine with me. If you want to test it locally, run:

node ./packages/create-analog/index.js

Choose analog-project as the name cd analog-project yarn yarn dev yarn build yarn test

The analog-project directory is ignored in git

LayZeeDK commented 2 years ago

Seeing that Vitest is currently only available in prerelease versions (<1.0.0), I suggest we don't match minor versions to prevent accepting breaking changes, that is:

{
  "devDependencies": {
    "vitest": "~0.22.1"
  }
}
Yberion commented 2 years ago

I agree about that, what do you think about updating patch version on every packages except the one we trust (like Angular) ?

For example, lib ~1.0.0 everywhere (except Angular packages)

brandonroberts commented 2 years ago

I'm fine with leaving the range to accept minor versions at the moment. We're still in a prerelease state also, so I'd like to know if something breaks with the latest feature version that gets installed.

LayZeeDK commented 2 years ago

My point is that 0.x.0 version bumps mean breaking changes while 0.x.y versions are non-breaking feature and bugfix releases if following semantic versioning for prereleases. You want consumers to accept breaking changes by default, @brandonroberts?

brandonroberts commented 2 years ago

At this point in active development, yes. I'm not planning on intentionally breaking anything but we still need room to stay updated.

When we move to a beta version for the plugin, I think it's ok to tighten up the versions to be more strict. If someone says their using this stack to build towards production today, we'll revisit this accordingly.