[Question] How are you handling npm tasks and dependencies? about webpacker HOT 7 CLOSED

@joerodrig3 @merqlove I was able to use jest without symlinks by setting NODE_PATH in vendor/package.json:

  "scripts": {
    "test": "NODE_PATH='./node_modules:../app/javascript' jest"
  },
  "jest": {
    "testPathDirs": [
      "../app/javascript"
    ]
  }

After that I just had to create a .babelrc in the root of my project, replicating my webpack plugin setup.

from webpacker.

@schpet Thanks for that! That actually seems a lot better than the symlink solution

from webpacker.

Hi, what is a problem to run bin/yarn?)
But yes, here easy to mistake, just first time.
Also you can try to run cd vendor; yarn

About tasks:
You can write any scripts you want in the package.json, then run it with YARN or with NPM.

from webpacker.

The concern I have with bin/yarn is that in some cases, such as deploying to Heroku, it seems like we have to create a yarn.lock file and package.json file in the root directory of the app anyway to trick Heroku into installing yarn as a dependency. What benefits are there to organizing those files in vendor if we need to create/symlink them in root to get our app deployed and/or get client specs running? It seems like creating these duplicate files adds unnecessary complexity, but I'd also like to know more about why the choice was made to move these files into vendor!

As 3rd party packages, I can understand why node_modules would be put in vendor, but it seems odd to me that package.json and yarn.lock would be put in there as well. I think of them as config files that you typically expect access to on the root level, similar to Gemfile and Gemfile.lock

from webpacker.

package.json must be at the same level, as modules folder. So if we have it at vendor level, then it's modules folder will be in vendor too.
But yes, for example in Phoenix framework node_modules, package.json sitting at the root level. And it just works.

About symlinks, yep it works like workaround, but better is avoid symlinks.

from webpacker.

from webpacker.

@schpet same here, also we can use Makefile :)

from webpacker.