Ability to copy all files and not only JS files when stripping types using `flow-remove-types`
bacloud22 opened this issue · 5 comments
Proposal
I think it is useful to have all files copied by default when using flow-remove-types. I for instance use .proto files inside code, you can imagine other useful extensions that generally go hand in hand with JS (like JSON, HTML..)
Use case
My build step is like "build": "flow-remove-types src/ -d dist/",, source folder contains files other than .js so the ./dist is not self contained anymore.
Note that we probably won't do it ourselves, since we don't really recommend using it. The implementation of flow-remove-types is quite hacky, and you will be better off using babel directly. We do accept community contribution.
I would like to work on this. Please assign @SamChou19815 🙏
OK understood about recommendation. But won't babel approach use the same whatever algorithm to remove types ?
I would like not to add babel at all, since I've never used it, and I don't need it.
Do you mean using flow-remove-types is not recommended at all ? For me it seems to build JS without types just fine. I've added a hacky way to preserve all files:
"build": "rm -rf dist/ && cp -a src/ dist/ && flow-remove-types src/ -d dist/"
first it copies all files and folders (including JS, not the best) then it ovewrites JS with the ones from flow-remove-types
But won't babel approach use the same whatever algorithm to remove types
No, babel will remove the types from the AST, and then print the result API back to code. That approach is much less fragile then the string manipulation approach based on ranges that's currently in flow-remove-types.
The only thing preventing us from deleting it from the repo is that we have not find an easy way to use the babel infra so that flow-remove-types powered flow-node, which can directly run flow code with the correct line number in stacktraces, still works.
The energy would be better spent on making the babel-based approach work by connecting it to the source map. That being said, we will still accept bug fixes and improvements to flow-remove-types before we work out the babel stuff.
Hi @SamChou19815
Understood! And thank you for explanations.
I still can work on this like you said, but it might take time for me to put my hands on code..