Static food data plugin. Transition to ES6
The current version of the plugin is ES5 version. And transition into ES6 development process it is one of our code organization problems. Check the previous article also: https://medium.com/groceristar/food-static-data-plugin-list-of-big-steps-66265919df0f
At this time — our plugin generates an issue at builds of React projects, created with help of create-react-app boilerplate. Our new toolset will have a default setup of js libraries: Babel, Rollup.js. We didn’t build our code, didn’t use ESLint and all available tests
Pros:
1. It will have a minification process and wouldn’t break a build of 6–12 React projects that we have right now
2. It will move from `code-commit` to `code-test-commit-publish_test` approach — which is a way better because robots will test what we’ve done.
3. Each time our code will be compiled so the code will be better by the magic of JS coding standards
4. It will have all ES6 features, that we partially use right now.
5. I am focused on this transition because I don’t like to have to keep the same things in a few places. As we didn’t finish it yet, we have a few repositories, where we are testing different features and trying not to break the main plugin. More tests — less confusion — better code quality — less number of new releases where we just fix some errors
Cons:
1. It a more complicated process of development. I will need to explain how to work at it to our team members. So It will require some of my time.
2. We still have a lot of unfinished stuff, that bothering me — I still don’t have “feeling” that we have everything inside at this repository(and I assume this feeling will stay)
3. Testing process in our new plugin is different. Each team member will require additional time in order to switch from the old way to a new one.
4. It will take at least a few weeks of work in order to completely change our rails. Right now only a few people working at the transition process.
5. We should upgrade/extend our testing part at the current version of the plugin. Right now it is not completed. But in order to speed up things, we’re splitting our tests into a few files, so it starts to look less overwhelming.
6. If we just move all of our code at the new ES6 version, we’ll need to replace JSON files, because sometimes it generates issues. The easiest way is to convert them into plain JS arrays or objects.
But we’ll need to do it only if we’ll keep our methods and static data at the same place. This is plus one to vote to split static data and JS code.
Our current testing process is not awesome. We can debug our methods at different places. In order to make it better, we create a file play.js at each folder. this plugin is only for developers, where we can make some output and compare changes. But this files can be pushed to npm repository, as we don’t have a nice build process at this moment. It will be fixed after a transition to Babel7 and Rollup.js version, where we’ll be able to orchestrate our processes better.
When I start to look at the transition process I find this cool repository. https://github.com/eunikitin/modern-package-boilerplate
It is important to understand how this project is packed, how it works, what is the development process. Actually, it’s very straightforward, but I have troubles for the first time when I see it. It is using Rollup.js, you can read more about it here(covered the basics of how to use Rollup.js for development of JS modules): https://code.lengstorf.com/learn-rollup-js/
Basic workflow:
1) you keep your code at `/src` folder. The file structure is not the same that we have right now. And it affects how you will debug your code.
2) When you complete your work, you run a build process and it will be converted to ES5 version and put into `lib` folder. If you want to debug your code and see how it works locally — when you build your code you can use `node lib/index.js` this will call the main index file.
Be aware, that sometime, your code will generate issues, because this plugin has a lot of cool features, that helps developers to produce better code. So your tests, your imports, your custom formatting can generate an issue. It’s ok, so we don’t need to worry about it a lot. But for sure, your code should be tested well.
Right now we actually build our own template with Babel and other important tools.
So we wouldn’t use that boilerplate, but we can use basic techniques from it. It’s also hard for me to think about moving 100% of the plugin into a new version. So I decide to do it in a stupid, but simple and maybe smart way :)
At this point, I created a few plugins, that like a bridge between our current `groceristar-fetch` plugin and between our next generation version of it. And I plan to move our functionality by parts. Moving one section of code, then test how it works, break something not important, fix it, then remove totally that part of functionality from the main project, etc. And then move to a new section
Thanks for reading!
