Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
What really is important are the changes in the dev-ui repository and package.json in the rest (which is repeated across all other modules), npm-shrinkwrap.json and yarn.lock files are generated. T...

What really is important are the changes in the dev-ui repository and package.json in the rest (which is repeated across all other modules), npm-shrinkwrap.json and yarn.lock files are generated. The change we're introducing here is locking dev-ui dependencies, which are no longer fetched to the node_modules in the root directory, but instead, are fetched into node_modules/dev-ui/node_modules. What we're doing is moving them to the node_modules directory so they are available to the module that is relying on dev-ui, lack of them there would break the build process because of missing dependencies. For yarn.lock we're basically copying the one generated in the .tmp directory, which is where we're firing yarn up during the build process. If you have any concern, please let me know.

These changes are virtually impossible to review in-depth.

These changes are virtually impossible to review in-depth.

It is.

It is.

I've just moved it, it was already reviewed.

I've just moved it, it was already reviewed.

I don't think we need to specifically say we've increased dependent service version, please remove this.

I don't think we need to specifically say we've increased dependent service version, please remove this.

Is version correct here?

Is version correct here?

dev-ui version update has a separate review - FEOLMIS-3344.

dev-ui version update has a separate review - FEOLMIS-3344.

Not really, the release process stays the same. The only difference is that at some point we will have to update those dependencies so they don't go outdated.

Not really, the release process stays the same. The only difference is that at some point we will have to update those dependencies so they don't go outdated.

Do we need any documentation? Something needs to be changed in release process?

Do we need any documentation? Something needs to be changed in release process?

missing changelogs?

missing changelogs?

OLMIS-3696: Added dependency locking
OLMIS-3696: Added dependency locking
OLMIS-3696: Added .npmrc, npm-shrinkwrap.json, yarn.lock files and postinstall script

  1. … 3 more files in changeset.
It's created by yarn

It's created by yarn

Where is the bower_components dir coming from now?

Where is the bower_components dir coming from now?

Revert "OLMIS-3415: migrate (most of) the dependencies to npm"

This reverts commit dcc0a66fb6e23489447bbc92f5bdfdc986049e5b.

  1. … 1 more file in changeset.
I agree that we should ultimately use webpack instead of bundling dependencies ourselves. I'll try using yarn for now. Unlike npm, it seems to be capable of getting single js files (analytics.js)

I agree that we should ultimately use webpack instead of bundling dependencies ourselves. I'll try using yarn for now. Unlike npm, it seems to be capable of getting single js files (analytics.js)

I'll give it a try. It seems that we will be able to get analytics.js with yarn

I'll give it a try. It seems that we will be able to get analytics.js with yarn

What about giving yarn a try? Bower even have a guide on how to do it - https://bower.io/blog/2017/how-to-migrate-away-from-bower/

What about giving yarn a try? Bower even have a guide on how to do it - https://bower.io/blog/2017/how-to-migrate-away-from-bower/

And, to be honest, it's something I would love to tackle personally.

And, to be honest, it's something I would love to tackle personally.

Other approach we could take is switching to webpack completely, but it might be really painful... We could cheese it a bit and postpone adding require everywhere but using require.context, but it ...

Other approach we could take is switching to webpack completely, but it might be really painful... We could cheese it a bit and postpone adding require everywhere but using require.context, but it would still be a significant amount of work to do, but most likely only here.

I guess that's the whole point of this ticket, isn't it?

I guess that's the whole point of this ticket, isn't it?

Should I continue migrating all the other components? If we did that, we could completely remove bower

Should I continue migrating all the other components? If we did that, we could completely remove bower

This task joins package jsons from all the services and installs their dependencies. With the initial "npm install" we only install development dependencies. Do you have an idea on how should we ap...

This task joins package jsons from all the services and installs their dependencies. With the initial "npm install" we only install development dependencies. Do you have an idea on how should we approach this?

This task feels redundant to be honest. We need npm in order to install grunt.

This task feels redundant to be honest. We need npm in order to install grunt.

Perhaps we should give yarn a try as migrating solely to npm seems problematic.

Perhaps we should give yarn a try as migrating solely to npm seems problematic.