Comments (4)
projen is all about avoiding templates. "Templates are evil" is our moto.
The main principle is that project types offer a surface area for users to define their project and we can easily implement a hierarchy of project types if there are use cases for more specific configuration.
For example, JsiiProject
is derived from TypeScriptProject
and specializes it for jsii use cases.
Let's take a use case you have in mind and I'll show you how we can add a project type for it.
#templatesareevil
from projen.
I'm not necessarily advocating for templates, I just wanted to clarify what is the better path for extending projen to support more specific use cases, as I thought we were working towards allowing templates since this.
There's a multitude of project "types" that support various use cases and I think it's important to make clear to which degree these use cases would be supported out-of-the-box. IMO, the downside of using "types" instead of templates is that the codebase might get pretty bloated and hard to maintain (if we're willing to support many), while templates live outside of the core APIs and therefore introduce less friction. I also see it as an easier path to adoption, since more flexibly supporting different use cases is more welcoming (if I have a cdk-jsii-construct template (or type), there's very little to customize in comparison with starting with the jsii type).
For example, here is what's currently working on my fork (API defo needs a better interface, but you get the idea):
Adding new project from template and customizing
.projenrc.js
const webFrontEnd = NodeProject.fromTemplate({
templateName: 'typescript',
copyFiles: true,
modifier: (proj) => {
proj.addFields({
name: 'my-project',
keywords: ['hello', 'from', 'async']
});
}
});
webFrontEnd.then(proj => proj.synth());
In the example above I'm using a template (which consists of a .projenrc.js file and sample code files) to instantiate a new projen project with changes. Since I'm using actual templates, changing template files is more flexible and straight forward.
I'm also using templates to manage monorepo packages like this:
Creating a monorepo project and adding a custom package based on template:
.projenrc.js
const myMonorepoProject = new LernaProject({
name: 'root',
lernaVersioning: true,
...common,
});
myMonorepoProject.addPackageFromTemplate({
template: 'typescript',
modifier: (proj) => {
proj.addFields({
name: 'dynageo',
keywords: ['hello', 'from', 'async']
});
}
});
myMonorepoProject.synth();
Using classes instead of templates just makes the above easier to implement. But how many types are we willing to support? Maybe open for extensibility with a projen+ kind of package? What about non-text files that might exist in templates, such as sample images?
from projen.
I'd like to start by using project types as the main vehicle for offering abstraction and not templates. Yes, they require thinking about APIs and surface area, but that's that whole point. Templates are evil exactly for that reason - they "seem easy" at first but very quickly they become completely unmaintainable and impossible to update.
When we reach 300 project types, we'll see how we can decentralize the ecosystem (it is always possible to import a project type from a library). At the moment, I think there is some value in keeping things simple and centralized. I added an Ecosystem section to readme with some info.
from projen.
Awesome!
from projen.
Related Issues (20)
- Request for Upgrade: `jsii` 5.1 to 5.3 HOT 1
- bug(upgrade-depdendencies): some dependencies are still attempted to be upgraded by ncu, then reverted by projen HOT 10
- Support modifying generated files HOT 2
- Projen npm package not updated with generated package HOT 11
- project initialization has dependency on yarn "classic" HOT 18
- Fails to publish a new package to npm HOT 3
- Better default for Jest UpdateSnapshot HOT 3
- `npx` used when `bun` is package manager
- bump and unbump share environment variable object
- spawn does not respect step envrionment variables
- Poetry console output not shown in real time
- New structure for `PythonProject` HOT 3
- Make GitHub pipeline run tests on multiple node versions
- Publishing v0.80.16 to PyPI failed HOT 1
- Publishing v0.80.17 to Maven Central failed HOT 1
- Should `args` be returned by the task --inspect CLI command? HOT 1
- Error when using `NodePackageManager.BUN` with `NodejsFunction` HOT 4
- Update actions due to node v16 deprecation notice: codecov/codecov-action HOT 1
- gitlab build workflow HOT 1
- Rerunning projen cannot proceed due to existing license. HOT 9
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from projen.