how to use this with webpack?

[quinn]

i have some typical setup in my package.json:

"scripts": {
  "start": "webpack-dev-server"
}

But when I run

lank exec -- yarn start

I get an error that the webpack-dev-server command is not found. When I run just yarn start it works, but then fails because it can't find the necessary code in node_modules/@scope/otherthing. I am running the command from a dir like code/@scope/firstthing and a lankrc in code/.lankrc.js.

[quinn]

Upon further inspection, it looks like lank exec runs on all of the projects being "lanked"? I don't get why i would ever want this. I think the more common use-case would be to run something for the current project in the lank environment. Just trying to understand better how this is intended to be used.

[ryan-roemer]

Hopefully https://github.com/FormidableLabs/lank#shell-commands can help explain more. For shell execution, it is a helpful wrapper to execute a command:

• On all of the linked projects
• On some of the linked projects by tags and/or modules names

Some examples:

# Git status on all linked projects
$ lank exec -- git status

# Run a build command on just the projects tagged "web"
$ lank exec -t web -- yarn run build

# Run tests on just a single project
$ lank exec -m my-module -- yarn run test 

... and all of that with Node.js require resolution working automagically between all the linked projects live on your file system rather than in each project's individual installed node_modules.

[quinn]

@ryan-roemer thanks for the quick response! the -m switch is what I needed, thank you. As far as i know, webpack's resolution is completely separate from node's so I assume this won't work with webpack?

[ryan-roemer]

Yes, that is correct ... but depending on your scenario, you may be able to alias your way to using Node.js require resolution within webpack as follows:

Say you have:

foo/
bar/

bar is a dependency of foo that you're linking. In foo/webpack.config.js you can do an alias like follows:

const path = require("path");

module.exports = { 
  resolve: {
    alias: {
      // Use Node `require.resolve` to find the correct project, even if outside
      // of this project.
      //
      // This looks funky, but there's a purpose. `require.resolve` will get
      // you into a subdirectory if `package.json:main` is set, and what you
      // really want the root of the project.
      bar: path.dirname(require.resolve(path.join("bar", "package.json")))
    }
  }
};

But, it does depend on how many linked projects there are, because for a lot, that may be a big pain. And, my resolve here finds project root -- your use within webpack may need an additional directory appended (like lib or es or whatever's appropriate).

We do use something like the above for some of our multi-repo projects that we develop with the aid of lank.

Hope that helps! (And if you've got a public repo of just a slimmed down version of "the problem" I can maybe take a look at your specific webpack config to advise further...)

[quinn]

ah, cool workaround, thank you. I'm maybe doing some stuff that is a bit unconventional. One of my goals is to not have to have separate webpack configs for everything, so I reference it like this in package.json:

  "scripts": {
    "start": "webpack-dev-server --config node_modules/@scope/frontend-configs/config/webpack.config.js",
  }

This way, all the apps can share a single webpack config. The restrictiveness of this is intentional. I've been using a combination of chokidar and rsync to keep this functioning in development, lol. I don't remember why, but symlinks did not work at all. IDK, may have to come up with my own runner because package.json doesn't allow for anything dynamic (and therefore no magic in where the files are located)

[ryan-roemer]

Perhaps not ideal, but you could shift to something like:

 "scripts": {
    "start": "webpack-dev-server",
 }

And then create a webpack.config.js in every project where each one consists of:

module.exports = require("@scope/frontend-configs/config/webpack.config");

Then lank's require resolution rules would control.

But you have correctly identified a limitation that lank doesn't control bash paths, etc. (Although maybe you could wrangle an env variable if only using bash or windows alone or something).

[quinn]

that could work, seems like a fair compromise. thanks @ryan-roemer , i'm going to close this because I think this is enough for me to continue.. thanks for all your help! i've been a Radium user for awhile now, y'all are doing some really cool stuff at FormidableLabs, keep up the good work :)