I have got a small radio service running on Node.js. Front end is written with React and packed with Webpack . I use Docker for my #DeploymentWorkflow along with Docker Swarm and GitLab CI on a single Google Compute Engine instance, which is also a runner itself. Pretty unscalable decision but it works great for tiny projects. The project is available on https://fridgefm.com
For our internal team and collaboration panel we use Nuxt.js (with TypeScript that is transpiled into ES6), Webpack and npm. We enjoy the opinionated nature of Nuxt.js over vanilla Vue.js, as we would end up using all of the components Nuxt.js incorporates anyways and we can adhere to the conventions setup by the Nuxt.js project, which allows us to get better support in case we run into any dead ends. Webpack allows us to create reproducable builds and also debug our application with hot reloads, which greately increased the pace at which we are able to perform and test changes. We also incorporated a lot of testing (ESLint, Chai, Jasmine, Nightwatchjs) into our pipelines and can trigger those jobs through GitLab CI. All packages are fetched through npm, so that we can keep our git repositories slim and are notified of new updates aswell as reported security flaws.
Github Actions has been a breeze to work with. Github Actions offers a nice CI/CD service right inside the Github environment itself. It comes with tight integration with Github. Github Actions workflows are triggered based on a variety of events, such as: commit, pull request, comment...etc.
At Cereo, we serve our Webpack bundle from Amazon S3 and Amazon CloudFront. We're using Github Actions to build bundles, upload them to S3, and invalidate Cloudfront cache. Our codebase is a monorepo with multiple apps. Github Actions lets us check updates using paths so that we can limit executions. Sometimes a pull request still triggers multiple workflows, but we get to run them concurrently with Github Actions. In fact, Github Actions can run up to 20 concurrent jobs.
That being said, don't try to change your entire CI/CD solution in one afternoon. Github Actions is still new to the market. Start small and build your new shiny CI system up.
#CI #ContinuousIntegration #ContinuousDelivery
Our whole Vue.js frontend stack (incl. SSR) consists of the following tools:
The main reason we have chosen Vue.js over React and AngularJS is related to the following artifacts:
I find myself struggling trying to use a specific minified CSS file under node_modules for Milligram in Phoenix Framework using Webpack. First I thought that I need to define a resolve entry in my webpack.config.js as described in css-loader docs.
Then, I've discovered that I can simply use this Webpack notation in my manifest file (app.scss):
@import '~milligram/dist/milligram.min';
As described in docs:
To import assets from a node_modules path (include resolve.modules) and for alias, prefix it with a ~
Note that if you have other Webpack loaders, it will expand your CSS file in development mode.
TL;DR: Shall I keep developing with Nuxt.js 2 and wait for a migration guide to Nuxt 3? Or start developing with Vue.js 3 using Vite, and then migrate to Nuxt 3 when it comes out?
Long version: We have an old web application running on AngularJS and Bootstrap for frontend. It is mostly a user interface to easily read and post data to our engine.
We want to redo this web application. Started from scratch using the newest version of Angular 2+ and Material Design for frontend. We haven't even finished rewriting half of the application and it is becoming dreadful to work on.
I'm currently trying to code a Proof of Concept using Nuxt.js and Tailwind CSS. But the thing is, Vue.js 3 is out and has interesting features such as the composition API, teleport and fragments. Also we wish to use the Vite frontend tooling, to improve our time developing regardless of our application size. It feels like a better alternative to Webpack, which is what Nuxt 2 uses.
I'm already trying Nuxt.js with the nuxt-vite experimental module, but many nuxt modules are still incompatible from the time I'm posting this. It is also becoming cumbersome not being able to use teleport or fragments, but that can be circumvented with good components.
What I'm asking is, what should be the wisest decision: keep developing with Nuxt 2 and wait for a migration guide to Nuxt 3? Or start developing with Vue.js 3 using Vite, and then migrate to Nuxt 3 when it comes out?
As someone who's been working in Nuxt since April 2018, I'd highly recommend to go ahead and forge ahead with Nuxt 2. All of the core fundamental hallmarks of Nuxt 2 will be present in Nuxt 3, and Composition API, teleports, etc. are all just building upon the foundation Nuxt 2 has. Same with Vue 2 to Vue 3. There's zero reason to feel pigeonholed into waiting for a release to come out. JS frameworks are always evolving, and you're going to find things that Vue 3 / Nuxt 3 simply might not be ready for that Vue 2 / Nuxt 2 have already fantastically implemented. I'd advise start building your app today and whenever Vue 3 / Nuxt 3 hits a release stage, then you can look at the migration path (which really shouldn't be that categorically complex) and decide whether there are enough performance and framework feature reasons to change. Even when you do change, it can be component by component - you don't have to change everything overnight. Better to get a head start with your app's construction than to delay and worry about which version of the tool to use to build it.
Better use the nuxt 2, and if nuxt 3 comes out.. I believe it will be easier to migrate because I believe the folder structure for nuxt 2 will also be the same as better use the nuxt 2, and if nuxt 3 comes out.. I believe it will be easier to migrate because I believe the folder structure for nuxt 2 will also be the same as the folder structure for nuxt 3.. so copy-paste folders and fix maybe s some errors, and done...
Hi, I am at a point when I discovered I need starter templates to kick off my web projects quickly and easily. I want to set-up my template code with the best or rather a packaging tool that is fast in compiling my Sass code and JS. Should I use gulp or Parcel or Webpack.
I need help please, A.S.A.P
Gulp is very old. I would not use it.
It all depends on what framework you are using. They usually come with a bundler. And templates often come with a bundler.
Webpack is the standard Webpack solution. But maybe complicated to use if it does not come with your template or framework. So you may wish to try Parcel first.
I'm looking for a library that can allow customization, relatively low effort integration with TypeScript, and ability to bring business users into the design process with a tool like Figma design. We are developing our own SDK for quick dev setup through Open API and build with Webpack and mustache templates. I know Flowbite comes with Typescript definition files out of the box but not nearly as supported as Material-UI. I need to understand what additional work having something that definitely will have long term support like Material UI converted into Typescript vs Flowbite that will have less support, but a typescript definition file out of the box, and what customizing components will do to the type definition files.
When considering long-term support, Material-UI is a better choice for a robust and well-documented TypeScript integration, offering strong community backing. Converting Material-UI into TypeScript may require some initial effort, but it's likely to have better scalability and support. On the other hand, Flowbite offers TypeScript definition files out of the box, making it quicker to integrate, but with less community support, customization could lead to additional maintenance, especially with component type definitions. For ease of customization and future-proofing, Material-UI may be a safer choice.
