Altering source import path

[gihrig]

I'm really liking ReactQL, You've hit a nice balance between out-of-the-box functionality and flexibility! 😄

So far, moving an existing project to ReactQL has been pretty painless.

I do have an issue I'm kind of stuck on at present though.

The original source project includes extensive configuration for Eslint, Prettier and Storybook. These use an import path which has ./src as the universal import path, rather than project root. So, imports look like this:

import GraphQLMessage from 'components/GraphQLMessage';

Rather than the ReactQL standard:

import GraphQLMessage from 'src/components/GraphQLMessage';

So I need to modify ReactQL or the existing project. I'm not opposed to modifying the existing project, but if there is an easy way to add src/ to the import path so components can just import ... from 'components/ComponentName' that would be preferable.

I have searched and found config/paths

  // Source path; where we'll put our application files
  src: path.join(root, 'src'),

which is used in ./kit/webpack/base.js and found:

  plugins: [
    // Options that our module loaders will pull from
    new webpack.LoaderOptionsPlugin({
...
      options: {

        // The 'context' that our loaders will use as the root folder
        context: PATHS.src,
...

I have fiddled with the config/paths.src setting, but that didn't seem to make a difference in the error I get when importing from 'components/...

Failed to compile.

Module not found: Error: Can't resolve 'components/GraphQLMessage'

Further webpack.LoaderOptionsPlugin seems to be deprecated as of webpack 2?

The LoaderOptionsPlugin ... is built for migration from webpack 1 to 2
...
This plugin will be removed in the future as it only exists for migration.

So I'm wondering if I'm totally off base in my search for a solution...

If there is a simple solution I would greatly appreciate that, if not, don't sweat it. I'm more familiar with the existing project and can modify that without too much difficulty.

Oops! found a solution just after posting this, see next.

[gihrig]

From kit/webpack/base

    // When we do an `import x from 'x'`, webpack will first look in our
    // root folder to try to resolve the package this.  This allows us to
    // short-hand imports without knowing the full/relative path.  If it
    // doesn't find anything, then it'll check `node_modules` as normal
    modules: [
      PATHS.root,
      'node_modules',
    ],

I just added PATHS.src, and - problem solved! I'm really lovin' ReactQL! 😁

[leebenson]

I initially thought of making PATHS.src the first import path. That would enable you to write exactly as you're doing - e.g. import 'components/x' instead of the slightly more verbose import 'src/components/x'

But on reflection, I think explicitly stating src vs. say, kit, makes it clear you're pulling in your own code and not something part of ReactQL proper. It also enforces a pattern of keeping things within src, which is the only dir that's 'safe' from overwrites when using reactql upgrade to bump kit versions.

So for now, I'll leave this as a userland exercise and stick with explicit src imports.

[leebenson]

Actually, one use case I hadn't considered until just now is kit shadowing.

Say you have kit/entry/browser.js that you want to override in some significant way, outside of config.* functions. You could potentially create src/kit/entry/browser.js which would 'shadow' the original whenever an import x from 'kit/entry/browser.js' statement is encountered.

I'll re-open this and test. If it works as expected above, that could potentially be a very nice feature.

[gihrig]

kit shadowing

that could potentially be a very nice feature

I agree, it would be valuable to have the ability to alter ReactQL's behavior without altering ReactQL's code, facilitating kit updates.

Some thoughts though:

1. Shadowing kit parts would not work for features not directly consumed by userland code e.g. webpack config.

2. Seems a bit extreme to entirely replace, rather than just extend a bit of ReactQL like 'kit/entry/browser.js'.

I acknowledge that shadowing is by far the simpler feature and would work in many cases.

Thank you for considering this.

[leebenson]

I've started using src as an implicit root in some of my own projects, and it's working out nicely. I'll get this added as the first look-up path in the next release.