stevedlawrence commented on PR #187:
URL: https://github.com/apache/daffodil-vscode/pull/187#issuecomment-1165469000

   Yeah, 2 +1's are required before this can be merged. Hopefully one of our 
many commiters can find some time to take a look.
   
   > I am working on a new way of handling the building
   
   Switching to node and your refactoring ideas sound very reasonable to me.
   
   I have no strong preference about `build` vs `src/scripts`.
   
   That said, my first thought is that it feels natural for only code that is 
part of the extension to go in `src/`, so any build related scripts that aren't 
directly part of the extension want to be somewhere else. For example, in sbt, 
all build related files are in `build.sbt` or `project/`, and `src/` is where 
the actual scala files go. So that might be an argument to have the scripts in 
`build/` or something.
   
   And if that's the case, maybe it makes sense to organize the stuff in build 
a bit diferently, e.g. `build/scripts` and `build/vsix` to make it clear what 
are just build scripts and what are files are for the vsix extension? Or maybe 
`src/` wants to become `extension/src`, and then the stuff currently in 
`build/` can go in `extension/resources/`, and then build related scripts go in 
`build`? Lots of options.
   
   Another related thought, though maybe not a good one, does it make sense to 
rewrite the build config in sbt? It looks like there are sbt plugins for things 
related to what we do:
   
   https://github.com/jokade/sbt-node
   https://github.com/stonexx/sbt-webpack
   
   Those look fairly old, so maybe they aren't maintained and it's not a good 
idea. But it would be nice to have only a single build system. And as difficult 
as sbt can be, it is fairly powerful. From what I've seen from yarn, it's 
pretty limited. Though, maybe the node changes you've suggested resolve those 
issues, and in a better way than old sbt plugins would.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to