Custom registries in JSPM from CI

Hacking my way to a working CI build with JSPM and custom registries

vados

3 minute read

I recently ran into a bit of trouble using JSPM from the Gitlab CI build for one of my projects – in particular, I’ve started separating my shared frontend UI code (projects like vue-component-library, a small collection of homegrown, badly designed UI components), and reusing across projects. One of the big issues I ran into was trying to run jspm build on projects that used some of the shared libraries, that were hosted on Gitlab and not Github.

Update JSPM (SystemJS) + JSDOM + Vue testing integration

More changes & improvements to my JSPM (SYSTEMJS) + JSDOM + Vue testing strategy

vados

5 minute read

tl;dr - JSDOM has updated so my testing code that uses it has updated as well, ignore the editorial and look at the code. A while ago, I wrote a bit about some code I often use for integration testing on the front end. Since “integration” can mean a lot of things, to clarify, I am referring to making sure components render the right HTML under certain states (not loading a full page, not testing the render function).

Stop Using React

BSD + PATENTS.md != F/OSS. Stop using React.

vados

6 minute read

tl;dr The BSD + PATENTS.md pattern is not F/OSS. Facebook is trying to goad you into entering a mutually assured destruction patent stalemate, but you don’t have nukes. They do. Stop using React, there are other better alternatives. Before you get into my thoughts, maybe you’ll want to look at some other debate from other strangers on the internet: Discussion of Facebook’s explanation on HN Discussion on Apache Foundation banning use of React on Reddit

Revisiting E2E Testing With Tape (on a new project)

Expanding my `tape` E2E testing methodology with some new tooling

vados

11 minute read

tl;dr I extend my UI component unit/integration testing methodology to do E2E tests. Look at the code, I basically add lots of nice context-setter-upper functions (that’s the official term) that makes it work and make it relatively clean. As hinted-to at the end (PS) of my previous post, recently after attempting (and succeeding, mostly) to set up full E2E testing in the backend of a haskell app I’m writing, I decided to switch to writing the tests in JS land (instead of Haskell land) due to some lack of library support for PhantomJS/Selenium.

JS component-centric libraries and my rationale for considering MithrilJS

An exploration of my current thinking on component-centric libraries and why I am heavily considering using MithrilJS in primetime.

vados

10 minute read

JS component-centric libraries, and why I’m considering MithrilJS for some major work Recently I’ve picked up a contract that requires taking a relatively old server-side rendered codebase with some JS bolted on to a more “modern” front end javascript stack. As those who do front end will immediately notice, just the notion of a “modern” front end JS “stack” can mean so many things (when it probably shouldn’t). There is a plethora of approaches, libraries, frameworks, ideologies to be found on the front end (possibly representative of programming in any niche as a whole).

Using jspm, systemjs, and vuejs together

Getting JSPM, SystemJS, and Vue.JS to play nicely together

vados

8 minute read

Using JSPM, SystemJS, and Vue.JS together tldr; There isn’t much much vue-with-jspm support outside of the systemjs-plugin-vue, so I made a thing that compiles jspm templates from html files, and JSPM+VUE is really working for me. Also, Vue.JS is the view library people should recommend to beginners. Not React. Lots of words about JSPM It looks like jspm isn’t winning the mindshare of new JS developers these days. Though I’m not sure I can blame anyone for not having mindshare left to give, with the constant onslaught of new libraries, frameworks, doodads and what-have-yous that pop up from day to day.