Allow setting an 'alias' in bsconfig sources to affect import paths?

[TomiS]

Having spent several unsuccessful hours trying to get a build working in a setup where we have some of the bs/reason source files in a symlinked folder, I figured I could suggest/ask following:

Would it make sense to add a new configuration option alias to bsconfig sources:

{
  "sources": {
    "alias": "myAlias",
    "dir": "path/to/symlinked/folder",
    "subdirs": true
  }
}

When this option is enabled, bucklescript would not generate import statements that use relative paths like this: ../../myFile

Instead it would always refer to files like this: myAlias/path/to/symlinked/folder/myFile

That would allow users of webpack and alike to force the build tool to interpret the alias and the following path however they feel like. Maybe this could help with some of the Monorepo issues too. What do you think?

EDIT: To be exact and provide some context, I've been able to run the bsb to build the .bs.js files over a symlinked path and even tweak webpack config to successfully build the whole thing by setting resolve.symlinks: false but there are really weird runtime symptoms like getting Invalid hook call errors relating to React contexts even if there are no duplicate dependencies. My theory is that some of the symlinked .bs.js files are imported from two different locations (it's possible because this repo symlinks to itself) that creates a situation where some of the .bs.js are duplicates. But I haven't been able to confirm this. And that's why I ended up thinking this alias feature might help making sure all imports always happen exactly how they should. But of course any other solution that increases the flexibility of configuring the build will also do. Probably allowing genTyped compilation to another folder (without insource:true) would also solve my problem.

[bobzhang]

how do you check the integrity of alias? Do you think if we provide an option to generate all js files in a single directory, would that make your life easier?

[TomiS]

About generating all js files into a single directory.

In our current setup we symlink something called platform repository containing js and Reason source files into multiple instances of customer specific installation repositories. We don't use package manager here because we want to keep the platform editable during the development of each installation. Installations contain at least a few Reason source files so it must be installation that builds the whole app, using mostly the code from the platform and 3rd party sources.

So what we need is the build system to be able to build all Reason sources by mixing both platform and installation together. My idea has been that, some of the bsconfig.json sources (of a single installation) point to "real/local" paths and some into symlinked paths. If ReScript is able to read all of the files, build them into one folder so that the possible symlinks in the source paths don't end up creating invalid import paths, then that's probably quite good enough for me at least.

So I guess the only difference this workflow has to using yarn linking, is that in our case the symlinked platform source folder is considered as equal to local source instead of a third party dependency.

About the integrity of the alias field

I'm not quite sure what you mean with integrity in this context, but if you're concerned about how would ReScript guarantee that the build actually works, I would say it probably doesn't need to do that. This option would be mostly for people who want to push the generated js files through another build system like webpack and make sure that it is configured so that the aliased paths actually point to a real folder that has the files. But I'm aware I might be over simplifying this a lot so I just figured I throw this idea here and if it doesn't make sense, let's just forget it :)

[TomiS]

After a bit more experimenting, I think generating js files (with flow/ts types) to a separate folder would solve this same problem mostly. So if that's something you've planned to implement, then this ticket can probably be closed.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.