A year or so ago we had 2 AWS accounts, one for dev and one for prod, but we had a number of services products hosted in the one account. This made billing more difficult because a number of things cannot be tagged. It also increases the blast radius for security related incidents.
We also use S3 for our state management, but this approach would work for any Pulumi state store.
To get started you need a root account…
The active directory configuration in AWS works by defining additional claims during login. Inside active directory you create a rule which looks like this
c:[Type == "http://temp/variable", Value =~ "(?i)^AWS-"]
=> issue(Type = "https://aws.amazon.com/SAML/Attributes/Role", Value = RegExReplace(c.Value, "AWS-", "arn:aws:iam::<rootaccount>:saml-provider/Myorg-ADFS,arn:aws:iam::<rootaccount>:role/Myorg-ADFS-"));
This maps any AD group the user is in starting with
AWS- to a AWS IAM Role.
The SAMLProvider’s name must also be
Myorg-ADFS otherwise the integration will not work.
Once you have created the AD rules to map your AD group into IAM roles you can just configure the SAML provider.
After we have…
Changesets is an awesome tool for versioning NPM packages and maintaining changelogs for projects, it is quickly becoming a part of all our projects, public and private alike.
The Changesets GitHub action is designed to open a pull request with a running changelog then that PR is merged to do the release. This is great when you want to control when you release to NPM, but we want to simply release to NPM as soon as a pull request with a changeset is merged.
GitHub actions have the GITHUB_TOKEN secret, but that token will not trigger actions when it’s used.
NX.dev is a great mono repo tool and it comes with a number of project types which reduces how much config you need to maintain.
One issue we have on our bigger mono repos is the TypeScript language service is quite slow, also we pay the cost of type checking in linting, building, local dev, testing etc.
To fix this we are moving to a setup where:
tsc -b --watchin a vscode task to give us quick incremental type checking
TypeScript project references are a reasonably new feature in TypeScript which allows you to break your project up into a number of smaller TypeScript projects. This improves compilation and VSCode editor speed/reduces memory usage etc.
You then can run
tsc -b in your repo and it will build each project in the right order.
Once built, projects reference the built artifacts (the .js + .d.ts files) rather than the source (ie, /dist, not /src). Essentially it allows TypeScript to treat our projects just like it treats NPM modules.
About 6 months ago I was struggling with dealing with config issue, mono repo perf issues and a few other things and stumbled across NX.
I quickly started using their project templates for React, Express, Node etc which was good for a time, but now the plugins it comes with for these tools are stopping me from adopting some of the really interesting tools coming out in the node ecosystem. Similar to when you hit the edge of Create React App. I want to use ESBuild, and Vite and TypeScript project references in my repos.
The good news is that…
I use both Jest for my tests and VSCode as my editor, here are a few little tweaks to config to make using these two tools together a little nicer.
Name: Jest Runner
VS Marketplace Link: https://marketplace.visualstudio.com/items?itemName=firsttris.vscode-jest-runner
Debugcode lens links above your tests allowing you to quickly run or debug a test!
You can configure VSCode to exclude node internals and improve the debugging experience with smart step by adding this to your VSCode config
When using PNPM I hit an issue where…
https://pnpm.io is a new package manager for the node space, it focuses on performance and best practices. We have seen a decent drop in clean install times for all our projects after switching from Yarn. Some projects dropped from ~2mins to ~30 seconds.
PNPM does not hoist all dependencies into your node_modules root, this means if the package.json doesn’t reference a dependency that your code require()’s or imports then it will fail to resolve.
This is the biggest hurdle in the migration but a very worthwhile exercise.
You can use this CLI flag to get around it if you really…
This is a bit of a brain dump for myself around the different options out there and some considerations for each. I am publishing as it may be useful for others.
It is far from an exhaustive list of options and I haven’t fully evaluated each, I just put together a list with initial pros / cons then picked one.
I will try to update each as I learn more about them and try them out more.
Building libraries you want to have at least a commonJS and ESM build available so your library works in the node ecosystem without…
Over the years I have setup and published a number of open source projects, ensuring they have automated builds/deployments and make it easy for me to accept pull requests then release a new version with ease.
There are a few parts which are often talked about in isolation:
A complete example setup is available at https://github.com/JakeGinnivan/example-project-structure
I prefer not using a tool which tries to do everything, instead use simple but powerful tools to bring everything together.
Tech lead for @sevenwestmedia WA | Speaker | Mentor | OSS enthusiast | Full Stack TypeScript, JS, React | Creator of GitVersion | 🥃 ☕️ 🐶 😸