Modern JavaScript practices and tooling

[sberney]

Are you at all interested in me adding a build with npm or yarn to install 3rd party dependencies, modifying your modules to ES6 syntax by adding babel, adding a rollup (or possibly webpack) based build to produce an optimized output (it might be fun to try out the google closure compiler too with either), and we can write a short script to generate those electron files?

I can also hook up lint, and can add flow typing if you like. I don't know what you know about lint, but it helps you find errors and simultaneously maintain stylistic conventions. The trick is configuring it to your stylistic convention, and mine is very much different than yours. Still, it can provide a lot of non-stylistic features.

It would be pretty straight forward for me to do this kind of stuff, but it would change your workflow by adding a build step. You would need node.js (and the bundled npm), and have to run npm watch to get the build to watch your file.

Are you interested in adding some tooling like this?

[Azgaar]

Hi @sberney,

Thanks for the suggestion! I'm ok with new ways of working, just not sure it can be done that easily. We have a lot of code and refactoring will take some time, while I cannot work actively these days. I don't think moving to webpack will make the tool significantly better, it will be easier to support, but still that's a lot of work and changing the paradigm at this point of time is a big change.

It may be a better idea to start with something small and doable in 1-2 days.

[sberney]

I agree that restructuring is a big project, but it's a lot easier if you have the tooling in place. I know exactly what you're saying.

Here's one process that puts off some of the more gnarly decisions:

1. Get lint working - lint is smart and can detect when imports are missing, and fun stuff like that.
2. Configure lint so that all the existing files pass linting - basically figure out where functions are
3. Get a build working that only builds main.js - doesn't affect code
4. Modify index.html to import the new built main.js, or possibly fallback to the unbuilt version for now; or create two index.html files - but it's just changing one file import.
5. Picking one module at a time, convert that module to export its utilities in ES6 format. The module should be used only by main.js or by other modules that are already converted - basically this amounts to adding export/import statements. It should go fairly quickly once that other stuff is there.

I did a little bit this evening to get the linter working. main.js currently passes lightly modified i-am-meticulous linting which is pretty sweet. If you clone [email protected]:sberney/Fantasy-Map-Generator.git and checkout feature/build-system, you can run npm install then npm run lint-main to run the linter on that file and see what it spits out. Here's the configuration I put together to make it succeed.

A lot of it is just silly book-keeping, writing down which variables and functions are currently globally available, and where to find them. In the future, the list would slowly dwindle until there aren't very many global methods. The linter can resolve ES6 style imports to make sure they work.

Anyway, the linter would eventually be part of a webpack build/watch process, or another bundler. Ideally, a build process goes something like: 1. install, 2. lint, 3. build, 4. test.

Thanks for working on this tool, it's really cool. I'll play around with it some more.

[Azgaar]

Hello. Yes, it can be useful, but still requires a lot of time to move to a new version. Not sure I have this time as I was not able to work on Generator since Christmas.

[iamsellek]

@sberney If you're going to do a refactor, consider adding TypeScript, too. It'll make it much easier for new devs to jump in and do work because they'll immediately be able to see what every object looks like without digging through the extensive amount of code that's in the project.

[Azgaar]

Closing as for now, PRs are welcomed.