Consider copying the file content instead of exporting it

[mgtitimoli]

Hi there,

I was just wondering why you choosed to export the original file instead of copying it directly, and the main reason behind my proposal is that with the current approach you need to preserve the src folder, while if the contents were copied, then it wouldn't be necessary to keep it.

[swansontec]

To accomplish that, we would need a tool that can recurse over Flow types and bundle them together into a single file. This is because your index.js probably exports stuff from other files, so we would need to include those types as well (or risk having broken definitions). Rather than implement such a complicated tool, I think it's simpler to just include the src folder in the NPM package.

Don't get me wrong, though! I would absolutely love to have a tool that can extract type definitions and bundle them all together into one big file! I just don't have time to write one right now. 🤷‍♂

[swansontec]

I should also mention that there is a tool called flow-copy-source which can copy your entire src directory into your output folder, renaming files from .js to .flow.js. However, this doesn't actually save any space compared to just including src as-is, since it's all the same files either way.

[mgtitimoli]

There is no need to recurse over Flow types, as you've already pointed out, the only thing required to acomplish what I wrote would be to replicate flow-copy-source behaviour, basically, copying the files passed to the plugin with .flow.js extensions

[mgtitimoli]

And the main reason behind this other approach would be to simplify the package folder structure, as if you copy all files with flow.js extension to the output folder you would be able to remove the src folder entirely from your package.

I'm doing what I wrote as a 2nd process after rollup using flow-copy-source, but I've recently started to work on a new package, so I researched a bit and I found this plugin you created so I opened this discussion to evaluate this other alternative.

[swansontec]

I used to use flow-copy-source, and it never really worked right for me:

• If you delete a source file, flow-copy-source won't remove it from the dist folder, so you end up with Flow errors in the packaged library from the leftover bits. I've had several failed publishes from this alone. This makes it necessary to fully remove & re-build the dist folder prior to each publish.
• If the rollup output doesn't match the entry file name, flow-copy-source won't know about this, so you need a tool like rollup-plugin-flow-entry to adjust the entry point in any case.
• Source maps refer to the source files in their original locations, so you probably want to include the source folder anyhow just for debugging.
• Copying the files doesn't actually simplify the package. Your package includes the exact same files either way, just with different names and in different places.

I get the aesthetics of shipping a package to NPM without the src directory. I felt the same way at first, but after traveling down this road for a few years, I no longer feel that way. There is an even great simplicity in just leaving the sources where they are, even if it isn't "pretty". Things just work better, with fewer moving parts.

The only downside I can see is if your source folder has a lot of assets, like images or CSS. In that case, copying over just the JS would be reasonable. This is the main use-case that would make me open to a flow-copy-source work-alike pull request, should someone submit one.