Compile dependencies in node_modules

[robmcguinness]

More libs are being written using syntax that is not compatible with certain browsers (IE11). The toolkit should compile everything from node_modules. Leverage Rule.oneOf (like cra) and then close https://github.com/Availity/availity-workflow/issues/98.

[djejaquino]

Would this support symlinked packages? Right now, I am compelled to compile my library because when/how are @availity/react uncompiled packages handled by the toolkit is a mystery to me.

[GoPro16]

Theoretically it should support symlinked packages as its just taking the source code and compiling it on its own in webpack.

For Science this is where we say all deps that start with @av are then compiled.

We have started taking steps to compile our mono repos. sdk-js is now all compiled which should come with some performance benefits but overall doesn't bind the user to using something like workflow or extra config to compile those packages.

[djejaquino]

So are newer formik-based @availity/react packages gonna join the compile dance?

Keep in mind that you might have to define webpack aliases for some global context bound libraries when working with symlinked packages, to prevent duplicate module inclusion, even though they are declared as devDependencies and peerDependencies, e.g. (workflow.js):

...
modifyWebpackConfig: webpackConfig => {
    webpackConfig.resolve.alias = {
      'formik': path.resolve('./node_modules/formik'),
      'react': path.resolve('./node_modules/react'),
      'react-dom': path.resolve('./node_modules/react-dom')
    };
    return webpackConfig;
  }
...

[GoPro16]

Ah I see where you are coming from now.

Yes we do plan on compiling those packages as well. Most likely it will be using the same babel script used to compile the sdk stuff.

[djejaquino]

We are using Typescript + RollupJS and I was not sure it would pay off moving to development.babelInclude. Now that I know the direction you guys are taking, we will stick with compiling ours too.

[djejaquino]

@GoPro16 remember this? I think it could be tracked here.

I have just started a new project using @availity/workflow and was able to detect at least three packages that prevent running in IE: react-refresh-webpack-plugin, query-string, react-dev-utils. I stopped there because felt like going too deep into the rabbit hole.

I tried using workflow's babelInclude option, but ended up with issues in Chrome too.

[GoPro16]

Hmmmm, okay I went ahead and disabled the experimental hot loader by default and pinned query-string to v5. Not sure why that was accidentally upgraded again. 🙃

[djejaquino]

It works in IE now, but I had to run npx @availity/workflow init to create a new project. Just npx @availity/workflow-upgrade was not enough.

[GoPro16]

Right upgrade is just used for jumping major versions. We need to update it again but the main goal was for upgrading the workflow dev dep and not fixing your dependencies although that would be neat 😄

[djejaquino]

...upgrade is just used for jumping major versions.

All right, I did not know that. Duly noted.

...and not fixing your dependencies although that would be neat

I mean, it could generate discussion about how invasive is fixing project dependencies, but I feel like workflow is kind of babysitting the project so much already I wouldn't mind.

Situations like this one, where a new workflow minor/patch version would fix a dependency or an internal config (i.e. babel, webpack, lint), can you imagine contributing to vendor open source repository, having a PR approved which triggers a build and NPM publish, then going back to your project and running an upgrade command and have it fixed? We are halfway through that already 😃