mediamonks / pota

Pota :tipping_hand_person: tools to carry your projects

Pota

Pota - a collection of tools to support the creation and management of Node.js projects.

• Create: Pota provides you with a set of officially supported and managed templates and scripts, which can be composed together into a project using the @pota/create command. It also allows you to bring your own template or scripts, if you already have something that you are comfortable with, but still want to utilize create-pota.
• Manage: Have you ever wanted to change something about your build tool, customize it or easily add new commands? The @pota/cli package and the scripts designed around it provide you with such possibilities.

All of this and more is possible through the pota command.

Getting Started

To get started, we recommend creating a brand new project using @pota/create:

npm init @pota

Packages

Package	Type	Version
@pota/create	Core
@pota/cli	Core
@pota/webpack-scripts	Scripts
@pota/react-webpack-scripts	Scripts
@pota/muban-webpack-scripts	Scripts
@pota/vite-scripts	Scripts
@pota/react-vite-scripts	Scripts
@pota/plop-scripts	Scripts
@pota/vanilla-template	Template
@pota/react-template	Template
@pota/react-base-template	Template
@pota/muban-template	Template
@pota/next-template	Template

Contributing

See CONTRIBUTING.md

License

Pota is MIT licensed.

pota's Issues

[Project Deployment] add deploy-scripts

@pota/deploy-scripts

Commands

• deploy - runs a script that deploys the project to some remote server

Description

All of the templates duplicate an rsync npm script that uses rsync to deploy the project bundle to some remote server. Some, such as the muban template, even duplicate the script 3 times for custom in/out paths.

This is quite annoying and hectic to manage, those scripts also do not provide any meaningful error message if the user does not have something properly configured (e.g. the config.host field).

The new package would have a deploy command that would execute that same rsync command, but would still allow configuring the in/out paths.

---

See #39 for context

Skeleton specific documentation

Porter skeleton creation is quite different compared to other project creation tools. While other tools usually require a .json file, for which you always need to have documentation open, porter only expects a potential skeleton to include a porter.config.ts file. It is designed to be a typescript file, so that you would have to refer to the documentation less and can trust that the jsdoc and type definitions can guide you through setting up a new skeleton. Importantly, this file defines what porter should include in the final project bootstrap, any transformations on the skeletons source files and finally provides a way to enhance porter with additional commands.

This should be explained with examples in a separate .md document.

update `@mediamonks/eslint-config-base` and remove `.prettierrc`

mediamonks/eslint-config#25 adds a default prettier configuration to @mediamonks/eslint-config-base, which means that our @pota/webpack-skeleton no longer had to include a .prettierrc file.

add a next.js template

features

• lint script
• format script
• typecheck script
• plop script
• rsync script
• lint-staged & husky
• pipelines

remove `format` script

All of the skeletons are using the @mediamonks/eslint-config-base eslint rule-set, which includes the eslint-plugin-prettier plugin. The eslint-plugin-prettier plugin already applies prettier's formatting.

This means that the format script that runs prettier is redundant and can be removed.

Add support for multiple template engines

From @ThaNarie in mubanjs/muban-skeleton#44

---

Currently, the skeleton can only render TS templates – which will stay the preferred way of working.

However, certain projects might benefit from other template languages – like Twig or Handlebars – that better connect with the CMS used in a project.

Since we're using express already to render templates "on the server", and @muban/storybook does support server-side template rendering, we could leverage that to basically support any template engine that express supports – and potentially more.

Goals

• Be able to render a page, using multiple nested templates
• Still allow our current "data" setup for pages, but those are passed to templates
• Still allow defining types for the nested template structure, even though it's not used in the TS templates anymore
• Add an endpoint to render individual templates "on the server", and configure storybook to load those (instead of the TS templates currently defined in the stories)

Approach (WIP)

In the MubanWebpackConfig > finalDevServer, make the setupMiddlewares allow for different types of template engines (or abstract it away as "plugins").

Example for handlebars:

devServer.app.engine('.hbs', engine({ extname: '.hbs'}));
devServer.app.set('view engine', '.hbs');
devServer.app.set('views', './views');

middlewares.unshift({
  name: 'pages',
  path: '/',
  middleware: ((req, res, next) => {
    res.render('home');
  }),
});

Update the MubanPagePlugin > generatePageAssets to (also) output the raw "page data" instead of (only) the rendered HTML, so the middleware above can make use of this data to render the page based on chosen template engine.

Currently running into issues also setting this in compilation.hooks.processAssets.tapPromise

assets[page.replace('.html', '.json')] = JSON.stringify(pageData);

TypeError: Invalid value used as weak map key

Support `create-pota` field from templates

create-pota needs to support a new create-pota field from template packages. This field will guide create-pota into showing prompts after come template selection, replacing the currently hardcoded "Select Scripts Package" prompt.

This of course means that we will have to split create-pota into 2 prompt sections:

1. choosing the project name and template
2. showing prompts based on the templates create-pota field

between 1. and 3. we will retrieve the template package.json for use in 3., we can also start downloading the template package here so there is less waiting around.

example pota field

package.json

"pota": { 
  "scripts": {
    "builders": [
      "@pota/webpack-scripts",
      "@pota/vite-scripts",
    ],
    "linters": ["@pota/lint-scripts"],
    "formatters": ["@pota/format-scripts"],
    "testRunners": ["@pota/test-scripts"],
    "codeGen": ["@pota/plop-scripts"],
  }
},

For starters we will have 5 categories for scripts, meaning that a template can have at most 5 additional script related prompts during create-pota.

• bundlers - code compiling/transpiling/bundling (e.g. webpack)
• linters - code linting (e.g. eslint, stylelint)
• formatters - code formatting (e.g. prettier)
• test-runners - testing (e.g. jest)

---

See #39 for context

Cannot initialise JS/TS language features in Vue project on VSCode

Steps to recreate:

1. run 'npx @mediamonks/porter create vue my-vue-app'
2. Open in VSCode
   (3. Add TS syntax)

In the first screenshot below, you can see the in-built VSCode JS/TS language features extension is loading in the porter vue project (left) but has already leaded and therefore disappeared from the status bar in another project (right).

I also used porter to create a react skeleton project, and the language features initialised successfully.

In Screenshot #2 I've added a simple function with typed parameters, but my IDE doesn't recognise type declaration TS syntax. Presumably this is because it's failing to iniatilise those language features.

Add a test runner to muban 2 template so that we can write tests

It's currently not possible to write tests because there's no test runner available. If we're adding a test runner we should also look at storybook integration.

@ThaNarie wrote a facade for testing-library that works with muban 2 iirc. This could work neatly with storybook if we create an addon similar to https://storybook.js.org/addons/@storybook/testing-react

ESLint ignoring unused imports in Vue

Steps to recreate:

1. Create a Vue project
2. Import but don't use a module

You can see in the screenshot below that I've imported the default HelloWorld component into a new Test component. Usually ESLint would flag that as a variable that has been declared but never used, but in this porter vue project ESLint doesn't complain at all.

I also initialised a multi-line, empty props object that wasn't flagged by ESLint at all.

new package - `update-pota`

The Why

One of the issues that pota has not yet solved is related to template updating - if you create a new project today with, v1.0.0 of the muban-template, and we later release a bugfix v1.0.1, then it will be up to you to manually edit your created project and add that bugfix. This is both annoying to the user, time consuming and also potentially error prone if there are a lot of changes, or they are complex.

To solve this, I suggest introducing a new CLI package update-pota that similar to create-pota, would download the template that the project has been bootstrapped with, diff that template with the project and then through a CLI prompt let the user apply any new changes.

Ideally we would track the commit hash of the template package and the version of it that was used to create the project and then compare those two hashes, creating a diff that could be applied onto the project. In case the user modified the project from the initial template, e.g. adding dependencies, then hopefully the diff would generate a merge conflict that could be resolved by the user.

As this would require some of the template related logic from create-pota, it would be smart to also extract that logic into a package that could be shared between update-pota and create-pota.

---

Tasks

These are quite general and should likely be turned into individual issues after some research is done.

• investigate how to diff a template package and a project
• investigate what is good way of guiding the user through the upgrade
• move template related logic to a shared package

use turborepo for building scripts

The scripts/ folder is setup using npm workspaces, this makes it easy to create scripts packages that extend from other script packages - we can manage and test everything locally, without having to publish and install via npm.

While convenient, this does make building those scripts a bit more tricky (this is mentioned in CONTRIBUTING.md). The developer needs to make sure to build the scripts in a specific order, or else things will break.

Instead of setting up a custom script that will constantly have to be updated with the proper order, I think we can take a bigger step forward and introduce turborepo for building the scripts. Not only will it let us set an order, but it will also cache those each build (TypeScript has the --incremental flag which generates a .tsbuildinfo file, but it is a bit annoying for clean builds).

---

The task should be as easy as adding turborepo as a dependency to scripts/ and then creating a turbo.json with a pipeline with all of the scripts ordered.

Vue DevTools not detecting Vue.js

Vue devtools doesn't work on a base vue skeleton set up with porter.

Ran npx @mediamonks/porter create vue and yarn dev. Opened project (see image) and devtools failed. Not a problem on projects set up with @vue/cli.

Using node 14.16.0, Yarn 1.22.10, Vue devtools 5.3.4 (base extension) and 6.0.0 beta 7 (for Vue3 support).

Merge tool and skeleton packages

The current setup of having separated packages for build tools and skeleton specific tools is nice because it makes future project upgrading possible. Additionally, you can use multiple tools in the same project, making some previously difficult workflows possible.

However, this is confusing.

First, there is no clear definition on what should be included in a build tool package or a skeleton package. It is difficult to come up with clear definitions as there are always grey areas - should a linting tool be part of the skeleton or build tool package? It can be used either during development, bundling or committing changes. Depending on the skeleton, the requirements are different and we can't have a clear definition.

Secondly, it is difficult and annoying to maintain. If there are changes than span both the build tool and the skeleton, then there are two packages that have to be changes and updated. This increases the maintenance time and also raises the entry barrier for contributors. This is even more visible for when someone wants to create a completely new skeleton with a new tool for porter: you immediately have to setup 2 packages and either 2 repositories or get down with a mono-repo. Most developers won't want to go through all of this hassle.

In summary, the 2 package requirement is inefficient and I think that, while it makes porter and its skeleton config easier to manage, the complexity for skeleton developers is too high. From a conceptual point of view, explaining that you need 2 packages also makes a lot of developers confused, "isn't it just a skeleton?".

I think the correct route would be to merge the tool and skeleton packages and make porter capable of managing nested skeletons. For example, we can have a base webpack skeleton which the react skeleton uses as a dependency. The react skeleton could extend webpack skeleton's configuration and change things specific to React. This way, we don't loose the composability and upgradability of packages, everything would just be more streamlined.

enabling the ignore-scripts npm config

Introduction

Since e3e4174, each template contains a npmrc file (converted to .npmrc once create-pota has converted the template into a project). As part of the security effort, we want to add and enable the ignore-scripts to that npm config file, so our projects are protected from malicious dependencies running unwanted scripts on our machines.

This change however, will make it less convenient for developers, as they will now have to run multiple scripts after npm install, so we should make sure to document exactly what they need to run and automate what we can.

Tasks

templates/

This generally involves some configuration, documentation and a bit of investigation into the dependencies - a good warmup.

• add ignore-scripts = true to each templates' npmrc
• add postinstall to package.json, let it be empty by default
  • document this in the README.md
• investigate if any dependencies need to run scripts
  • add them to the postinstall

scripts/

• investigate if any dependencies need to run scripts
  • add them to the postinstall
  • document this in the README.md

create-pota/

This is where the above comes together.

• detect if the used template has any scripts
  • inform the user that they need to run them after postinstall
• if a script is being installed, add its postinstallto the postinstall of the newly created project
  • (e.g. npm run postinstall --prefix=node_modules/@pota/webpack-scripts)

hello, I am a test issue

Enhance message for users running a project on a used port

Running a dev server of a muban project installed through pota on a port that is already in use confronts the user with a wall of feedback. It feels this could be handled more gracefully or even better: a suggestion to run the project on a different port.

replace `seng-generator` with `plop`

Internally we made the decision to switch over from our in-house developed seng-generator to Plop for code generation.

Muban Template: Unlock locked packages

The muban template has a dependencies (storybook addons) when upgraded to latest versions will cause npm install to fail.

This has been remedied in this commit by locking addon package versions.

Next step: "unlock" these dependencies again and resolve this issue properly.

[Formatting] add format-scripts

@pota/format-scripts

Commands

• format - runs a code formatter, with auto-fixing
• format:check - runs a formatter, that reports back any formatting issues

Description

We have already been using a setup similar to this in most of our templates, for example the @pota/muban-template:

package.json

"scripts": {
  "format": "prettier \"**/*.{js,jsx,ts,tsx,scss,md,json}\" --write --loglevel warn",
},

The commands can be implemented using prettier.

---

See #39 for context

Template Testing

To improve the reliability of our templates, we need to make sure that they are properly tested before publishing. Currently this is a tedious and error prone manual process of running whatever npm scripts are included in the project and testing the template against each of the scripts packages that it supports.

We need a way to automate this, so that we can quickly and easily confirm that a template is working as expected; the solution should also be something that we can easily reuse in a CI/CD tool (#2).

What exactly needs to be tested?

For each template we need to test the following things:

1. a fresh npm install without package-lock.json
2. running each npm script
   • this is both easy and complicated - some scripts might throw an error, while for others, like plop, we need to confirm that they successfully accomplished their task
3. running the template against every support scripts package

3 is the only one that I would consider "up in the air", as we might want to do the reverse for scripts packages - testing a script package for each template that it should support.

"Could not determine executable" when running npx command using Node 15

In the image below, you can see the error that was thrown in my terminal.

Tried to run an npx command to use the react skeleton and received Could not determine executable to run.

Checked my npm version: 15

Tried running npx commands for react-base and vue, but got the same error.

Switched to node 14

Then able to use all npx commands successfully.

CI/CD

The process of publishing a pota package is fully manual now:

1. make changes and commit them
2. do npm version <newversion>
3. do npm publish
4. commit the new version with a message signifying the new version

Ideally, we would replace the last 3 steps with of a github action, that could be manually triggered for any of our packages. Later on, we can add onto the actions and have them test the code as well (e.g. #55)

Cannot run plop in React template

Expected result

When running npm run plop the plop wizard should start.

Actual result

The script will throw the following error:

> TS_NODE_PROJECT=tsconfig.tools.json node --loader ts-node/esm ./scripts/plop.ts

(node:51655) ExperimentalWarning: --experimental-loader is an experimental feature. This feature could change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
/Users/mickjasker/Documents/projects/video-editor/node_modules/ts-node/src/index.ts:820
    return new TSError(diagnosticText, diagnosticCodes);
           ^
TSError: ⨯ Unable to compile TypeScript:
error TS5083: Cannot read file '/Users/mickjasker/Documents/projects/video-editor/tsconfig.tools.json'.

    at createTSError (/Users/mickjasker/Documents/projects/video-editor/node_modules/ts-node/src/index.ts:820:12)
    at reportTSError (/Users/mickjasker/Documents/projects/video-editor/node_modules/ts-node/src/index.ts:824:19)
    at createFromPreloadedConfig (/Users/mickjasker/Documents/projects/video-editor/node_modules/ts-node/src/index.ts:835:36)
    at create (/Users/mickjasker/Documents/projects/video-editor/node_modules/ts-node/src/index.ts:597:10)
    at register (/Users/mickjasker/Documents/projects/video-editor/node_modules/ts-node/src/index.ts:564:15)
    at Object.registerAndCreateEsmHooks (/Users/mickjasker/Documents/projects/video-editor/node_modules/ts-node/src/esm.ts:126:34)
    at file:///Users/mickjasker/Documents/projects/video-editor/node_modules/ts-node/esm.mjs:8:7
    at ModuleJob.run (node:internal/modules/esm/module_job:185:25)
    at async Promise.all (index 0)
    at async ESMLoader.import (node:internal/modules/esm/loader:281:24) {
  diagnosticCodes: [ 5083 ]
}

Enviroment

MacOS 12.3.1
NodeJS 16.13.0
NPM 8.1.0

Possible solution

The problem seems to be that the tsconfig.tools.json is missing from the template causing the error.

Lint all code in repository

There are currently no linters configured for the code that is not part of the templates. We should enable linters for all code in the repo.

Please see this chapter in the @mediamonks/eslint-config repo README.md

[Storybook] add storybook-scripts

@pota/storybook-scripts

Commands

• storybook - runs storybook in development mode
• storybook-build - bundles storybook stories

Description

Managing storybook together with scripts packages is annoying. We either need to leave the script package config integration to the developer or (what we do now) assume what script the template will be using, neither is great.

storybook-scripts would include the base configuration for storybook, for each framework that we support. This would also help us manage the plethora of storybook related packages in a single package, instead of putting it onto the developer.

---

See #39 for context

[Linting] add lint-scripts

@pota/lint-scripts

Commands

• fix - runs all fix commands synchronously or in parallel
• fix:scripts - runs a JavaScript/TypeScript code linter, with auto-fixing
• fix:style - runs a CSS/SASS/Styled Components code linter, with auto-fixing
• lint - runs all lint commands synchronously or in parallel
• lint:scripts - runs a JavaScript/TypeScript code linter
• lint:style - runs a CSS/SASS/Styled Components code linter

Description

We have already been using a setup similar to this in most of our templates, for example the @pota/muban-template:

package.json

"scripts": {
  "fix": "run-s fix:* && npm run format",
  "fix:eslint": "npm run lint:eslint -- --fix",
  "lint": "run-s lint:*",
  "lint:eslint": "eslint . --ext .ts,.tsx --cache --cache-location node_modules/.cache/.eslintcache"
},

The fix and lint commands are implemented using npm-run-all, and fix:eslint is just running lint with an additional --fix argument for eslint.

scripts linting can be implemented using eslint and style linting can be implemented using stylelint.

---

See #39 for context

Not recognising lang=scss in style tags

Set up a new project using npx @mediamonks/porter create vue and the default stylings did not show in the HelloWorld component. Once I removed lang=scss the styles were applied.

Make default branch name 'main' instead of 'master'

Currently, when you create a package the default branch that is created is called master. Because the term is quite loading culturally I think it's better to change this to main like GitHub now does by default.

Ref: https://www.theserverside.com/feature/Why-GitHub-renamed-its-master-branch-to-main

Dev/build server failing on execution

When npm run dev or npm run build are run the following error is thrown:

file:///**/project/node_modules/@pota/webpack-skeleton/pota/webpack/getConfig.js:21
  if (path) return (await import(path)).default;
                    ^^^^^

SyntaxError: Unexpected reserved word

Inspecting the getConfig file you can see that the function that this piece of code is part of is not an async function triggering the error.

[Storybook] Notify the user about stories that use the mock-api

Introduction

So on one of my projects we use the mock-API in multiple components, since Storybook doesn't start up the mock server by default we might end up with stories that appear broken because of XHR requests failing.

Suggestion

To avoid the stories from being broken we basically have two options:

1. Always enable the mock-API when starting up Storybook so all stories work like expected.
2. Gracefully let the user know when a story requires the mock-API to be enabled.

The first option is probably the easiest to implement but it also has a downside because always running the mock-API causes extra processes to be started that might slow down the stories that do not require the mock-API.

The second option might be better for performance but also requires users to mark stories as API-dependant and would require some form of UI that instructs users to start up Storybook with the mock-API enabled.

Remove node-sass dependency from muban webpack scripts

Currently we have a node-sass dependency in muban-webpack scripts. node-sass is included as dependency of node-sass-json-importer.

Suggestion is to remove the node-sass-json-importer as dependency. Add the code of the library to our scripts as the dependency is unmaintained. On top of that node-sass is not required for that dependency to work.

Error while installing react skeleton

Hi @psimk

I'm having an issue while trying to install the react skeleton.

I got: Unexpected token '?'

I'm using:
Node 12.13.0
NPM version 6.14.4

[webpack-scripts] are broken in folders with spaces due to postcss-normalize

> pota dev

Error loading dependency '@pota/react-webpack-scripts/config':
Error: Cannot find module '@csstools/normalize.css'
Require stack:
- /Users/xxx/Desktop/MediaMonks%20Working%20Directory/xxx/node_modules/postcss-normalize/index.mjs
    at Function.Module._resolveFilename (node:internal/modules/cjs/loader:956:15)
    at resolve (file:///Users/xxx/Desktop/MediaMonks%20Working%20Directory/xxx/node_modules/postcss-normalize/index.mjs:57:46)
    at file:///Users/xxx/Desktop/MediaMonks%20Working%20Directory/xxx/node_modules/postcss-normalize/index.mjs:15:22
    at ModuleJob.run (node:internal/modules/esm/module_job:193:25)
    at async Promise.all (index 0)
    at async ESMLoader.import (node:internal/modules/esm/loader:533:24)
    at async loadDependencies (file:///Users/xxx/Desktop/MediaMonks%20Working%20Directory/xxx/node_modules/@pota/cli/lib/createCommand.js:48:51)
    at async file:///Users/xxx/Desktop/MediaMonks%20Working%20Directory/xxx/node_modules/@pota/cli/lib/createCommand.js:68:30 {
  code: 'MODULE_NOT_FOUND',
  requireStack: [
    '/Users/xxx/Desktop/MediaMonks%20Working%20Directory/xxx/node_modules/postcss-normalize/index.mjs'
  ]
}

This is because postcss-normalize has a funky way of resolving modules.

For now, a solution would be to create a big warning (or even abort with an error), if users are running pota-cli in a project folder that has spaces somewhere in the path.

Tool capabilities

Currently the tools provide 2 sub commands

• dev - start the development server
• build - create a production build

What other sub commands should the tool provide?
perhaps:

• serve - start a local server for a production build

What options should these sub commands allow?

• build --parallel - allow building multiple configs in parallel

What and how should be made customizable to the end user?
Currently we allow defining a custom webpack.config.ts

Define proper Tool/Skeleton API

Currently the cli, tools and skeletons use the porter-dev-utils package to share their code.
It contains a series of commonly used functions and constants, but no proper API or guide on what and how these functions and constants should be used.

[webpack-scripts] are broken on Windows due to postcss-normalize

This PR csstools/postcss-normalize#65 fixes an issue with postcss-normalize that breaks webpack dev/build on Windows currently.

That package is using broken and unsupported internal node functions to resolve folders on Windows.

I tested the patch, and that's working fine:

diff --git a/node_modules/postcss-normalize/index.mjs b/node_modules/postcss-normalize/index.mjs
index 03594d3..7c2f333 100644
--- a/node_modules/postcss-normalize/index.mjs
+++ b/node_modules/postcss-normalize/index.mjs
@@ -1,5 +1,5 @@
 import postcssBrowserComments from 'postcss-browser-comments';
-import Module from 'module';
+import { createRequire} from 'node:module'
 import path from 'path';
 import { URL } from 'url';
 import fs from 'fs';
@@ -8,9 +8,8 @@ import postcss from 'postcss';
 const assign = (...objects) => Object.assign(...objects);
 const create = (...objects) => assign(Object.create(null), ...objects);
 
-const currentURL = import.meta.url;
-const currentFilename = new URL(currentURL).pathname;
-const currentDirname = path.dirname(currentFilename); // get resolved filenames for normalize.css
+// create package path resolver in an esm-compatible fashion
+const {resolve: requireResolve} = createRequire(import.meta.url) 
 
 const normalizeCSS = resolve('@csstools/normalize.css');
 const normalizeDir = path.dirname(normalizeCSS);
@@ -54,11 +53,7 @@ const resolvedFilenamesById = create({
 }); // get the resolved filename of a package/module
 
 function resolve(id) {
-  return resolve[id] = resolve[id] || Module._resolveFilename(id, {
-    id: currentFilename,
-    filename: currentFilename,
-    paths: Module._nodeModulePaths(currentDirname)
-  });
+  return resolve[id] = resolve[id] || requireResolve(id)
 }
 
 const cache$1 = create();

If you place the above file as postcss-normalize+10.0.1.patch in the project's patches folder, and run npx patch-package, it will apply the fix for you.

---

I'd would like to have created a PR for this, but i'm not sure how this would work for script packages. As currently patches only exist in templates, and some templates are compatible with multiple script packages, there is no obvious place to do this.

Maybe we should create a new ticket to add support for scripts-patches.

react-template: update to React 18

React 18 has been released for around a month now (blog post), and its about time that we upgrade to it. The React team has promised that the upgrade should be fairly easy and smooth (outlined this blog post).

However, we should not just blindly bump the version numbers and follow the upgrade guide - we use a number of libraries and have utilities setup for them that might no longer be ideal. This requires some additional research and testing:

state management

For state management we are using mobx, and according to mobxjs/mobx#2526, it does not seem like mobx has or will have proper concurrent feature support. The issue boggles down to the maintainers suggesting to structure your app in such a way that the observable mobx store is separated from your React components, and all state is still managed by useState. In my eyes this makes things more complicated, and might only makes sense for large scale applications where we can control the architecture and be more strict with it. For most projects, we need something simple and easy to use.

I think we need to investigate other state management solutions, as a there is a lot to choose from now, and some of those solutions like zustand, do support concurrent features.

strict mode

StrictMode has become even more strict. I think we should disable it by default, but provide an easy way to enable it, so developers know that its is an option and something that they should test.

something else?

...

add aem-nextjs template

We need to add aem-nextjs template to easy bootstrap feature projects with aem. Have a look example above. There is using aem-react-editable-components package

Allow custom skeletons

Currently porter has a closed system - it does not allow for custom skeletons. This immediately makes it less useful, as there are cases where developers might have multiple project types, all of which would benefit from custom skeletons.

Now that refactor skeleton configuration is merged in, you can pass any package as a skeleton to porter create. This also makes it possible to use git or even local package skeletons.

# local
porter create file:../my-local-skeleton my-new-project

# git
porter create psimk/my-remote-skeleton#branch my-new-project

Additionally the --cli argument has been added, so you can also specify the package and version of the porter CLI that will be used in the created project.

# local
porter create react my-react-app --cli @psimk/porter-but-not-really

With this, it means that the only remaining thing to make customizable is the tool itself. Currently skeletons specify what tool should be used with them, this should be overridable.

[Code Generation] add plop-scripts

@pota/plop-scripts

Commands

• plop - runs plop

Description

We have already been using a setup similar to this in most of our templates, for example the @pota/muban-template:

package.json

"scripts": { 
  "plop": "node --loader ts-node/esm ./scripts/plop.ts",
},

We are not going to be generalizing plop into a code-gen command as the plop templates and plopfiles are specific to plop itself, so if we ever want to switch to a different package, we would have to throw everything out and start from scratch.

---

See #39 for context

SVG import error using react-template

While using react-template, importing SVG throws an error:

Syntax Error: Error: Plugin name should be specified at Array.map (<anonymous>)

Version:
"@pota/react-webpack-scripts": "~1.0.3"

Here is the diff that solved my problem:

diff --git a/node_modules/@pota/react-webpack-scripts/lib/config.js b/node_modules/@pota/react-webpack-scripts/lib/config.js
index 0c9c06b..7dbc969 100644
--- a/node_modules/@pota/react-webpack-scripts/lib/config.js
+++ b/node_modules/@pota/react-webpack-scripts/lib/config.js
@@ -49,14 +49,22 @@ export class ReactWebpackConfig extends WebpackConfig {
                     options: {
                         prettier: false,
                         svgoConfig: {
-                            plugins: [{ removeViewBox: false }],
+                            plugins: [ {
+                                name: 'preset-default',
+                                params: {
+                                    overrides: {
+                                        removeViewBox: false,
+                                    },
+                                },
+                            }],
                         },
                         titleProp: true,
                         ref: true,
                     },
                 },
-                { loader: 'url-loader' },
             ],
+            issuer: /\.[jt]sx?$/,
+            resourceQuery: { not: [/url/] },
         };
     }
 }

Create a changelog and github releases

Pota is a collection of different tools, so it is vital that we provide a digestible changelog that is updated with each new release.

`@pota/create` should fail if the npm version is below 7

Error when running npx porter create on npm v7

In npm 7, the 'npx' command has been changed to use 'npm exec' under the hood.

reference: https://github.blog/2021-02-02-npm-7-is-now-generally-available/

Tested on node v15.10 with npm v7.5.3

When running npx porter create react my-react-app, npm errors with could not determine executable to run

Import the main.scss file into storybook

We should also import the src/styles/main.scss file into our .storybook/preview.js file to ensure we get the same global styling within the iframe as we do on the dev server.

Script Abstraction

This issue discusses the next milestone for Pota and also outlines individual issues that need to be completed to reach that milestone.

Next Milestone

Pota released with template and scripts packages, templates are your base project boilerplates and scripts are collections of JS scripts that interact with your project in some meaningful way, e.g. bundling.

Currently there only exist scripts packages for bundling, we should move forward and continue abstracting more project utilities inside of scripts packages. As we have already experience with abstracting bundlers, placing linters, code generation tools, test runners and formatters into their own scripts packages would help reduce redundancy between templates, make testing these scripts packages easier - and for the end user - simplify their usage and make for easy upgrades.

New Scripts Packages

• #45
• #44
• #43
• #42
• #41
• #57

More Agency for Templates

Abstracting scripts away from their templates creates a problem - "how do we later include them in new projects?".

When creating a new project, currently, create-pota adds @pota/cli and a selected scripts package. create-pota itself is also responsible for "knowing" what scripts package a template supports, this is awkward as if we upgrade a template to support a new scripts package, then create-pota needs an update as well.

We should allow templates to define a pota field in their package.json, similar to how scripts use it to describe their commands. This field would describe what scripts packages can work with the template, which are recommended, their grouping (bundler, formatter or linter)and if needed the combination.

That field could then be picked up by create-pota and guide the creation tool into what prompts it should show. This also means that templates that do not have a pota field defined, will have no additional prompts related to scripts.

• #40

[Test Runner] add test-scripts

@pota/test-scripts

This requires additional research before we can make a sound plan on what we want test-scripts to be.

• what test runner package should we use?
• is this purely for unit testing or also e2e?
  • if only unit testing, should this then be @pota/unit-test-scripts ?
• what things should it support out of the box? (there will be test-scripts packages for each framework)
  • code coverage?
  • running in watch mode?

---

See #39 for context

Update core and scripts to TypeScript 4.7 Beta

As expressed in the CONTIBUTING.md, we are using a nightly version of TypeScript to support outputting ESM modules. Now that the TypeScript 4.7 Beta has been released (blog post), we can update to it, and be ready to move to a stable TypeScript version, once 4.7 is released.