swellaby / generator-swell Goto Github PK
View Code? Open in Web Editor NEWHighly opinionated Yeoman generator for various types of Node.js, Angular & Aurelia projects with TypeScript.
License: MIT License
Highly opinionated Yeoman generator for various types of Node.js, Angular & Aurelia projects with TypeScript.
License: MIT License
The badges for SonarQube appear to be broken
CircleCI (relatively) recently released the next major version of their platform. I think we should explore potentially updating our existing CircleCI config (1.x) to the new version, and perhaps see whether or not that would allow us to abandon Travis-CI (as opposed to using both of them like we do today)
https://circleci.com/features/
https://circleci.com/docs/2.0/
https://circleci.com/docs/2.0/migrating-from-1-2/
At the time I originally set the builds up, I was torn as CircleCI had some features I wanted that Travis-CI did not (test result tracking for one), and vice-versa (Travis-CI had a better set of integrations with other tools/platforms).
My initial thoughts of what we would need to have in CircleCI 2.x to drop TravisCI:
**** As a sidenote, I've opened up #98 to explore/consider using Appveyor so that we can have public CI builds for Windows too. The release pipeline in VSTS does run the same validation suite on Windows but I'd personally still like to use Appveyor in order to have publicly viewable builds, builds/comments on PRs, a Windows build gate for merges, etc.
FYI - @skjr001 @marjorienorm @beverts312 @rucheeg in case anyone has thoughts/concerns/questions/etc. (especially if someone wants to take this one!)
(Edit) - Added the issue link for #98
We have CI builds on pushes, PRs, and merges today that run on both Travis-CI and CircleCI on Linux. (see #97 for a proposal to potentially move that to 1)
I think we should have the same for Windows, in a publicly accessible place like Travis/CI, and Appveyor seems to be the defacto option for OSS builds on Windows.
I propose we explore/consider using Appveyor so that we can have public CI builds for Windows too. The release pipeline in VSTS does run the same validation suite on Windows but I'd personally still like to use Appveyor in order to have publicly viewable builds, builds/comments on PRs, a Windows build gate for merges, etc.
The module published to npmjs contains a bug wherein the generator does not create a .gitignore file. I am fairly certain this is due to the configuration of the .npmignore file of the generator itself
TypeScript 2.1+ supports a new compiler option that shifts generated helper functions (such as those generated from using 'async/await' or 'extends' in TypeScript) into a separate library instead of emitting those helper functions into the corresponding JavaScript output for each file using those features.
This re-enables achieving 100% code coverage
Currently the generator scaffolds out support for three linters in new projects: TSLint, ESLint, and JSHint. While I think it is important to support linting of the source TypeScript as well as the source & emitted JavaScript (lots of reasons, can discuss if needed) I am now seriously questioning if we should continue to have the generator supply two linters for the JS.
I am thinking/proposing we update the generator to just provide ESLint and no longer include JSHint in created projects. Here's why:
Thoughts @beverts312 or anyone else?
Update prompt configuration to include the following:
Tasks are currently referencing cmd
The packaged generator (as downloaded from npmjs) has a bug currently where much of the content that is supposed to be scaffolded is ignored.
This is caused by the recently added .npmignore file. I forgot that the npm package/publish process looks for both gitignore and npmignore files at every level of the directory tree. The template npmignore file is actually resulting in some of the template content (most of what is in the boilerplate template directory) being excluded from the packaged generator, and thus not scaffolded.
Will fix momentarily
ESLint has essentially been disabled for the vast majority of the generator codebase (currently only executing against the gulp tasks). Need to re-enable this and fix the errors
Before the 1.0 release we should figure out what license we want and stick it in the repo. My gut instinct is MIT or Apache, but probably worth a little research.
@beverts312 or anyone else have any thoughts?
@swellaby/core-collaborators - I think one of the next big focuses should be on a suite of automated functional tests. I've discovered throughout this process that testing of Yeoman generators is a bit different than a typical node.js codebase. For example, the "unit" tests are done with a specialized yeoman testing framework, but under the hood this framework actually executes part of the generator within a temporary directory and then cleans it up.
Our unit tests are providing us with verification that the generator is scaffolding the correct things, but it doesn't tell us whether the things that are scaffolded function correctly. For example, our unit tests ensure that the correct gulp task files are created but we don't currently have an automated way to verify that those generated gulp tasks correctly perform their function (lint, test, etc.)
I typically like using shelljs (along with mocha of course) to run functional tests against node cli apps (like yo) so that is going to be my recommendation here.
Thoughts? Objections?
The npm build script is experiencing in inconsistent behavior that sometimes fails. The error appears to be caused whenthe eslint gulp task kicks off at the same time some of the unit test setup methods are starting. For some reason this results in the eslint task failing, and throwing an error which makes the tests error out.
Until recently this had only been observed on Linux but now appears to happen periodically on Windows as well.
index-tests.js
is becoming too large to manage. We should refactor it into separate files.
We should also consider refactoring index.js
to be more files. I think thats a discussion we should tie into this issue because it may impact our strategy for refactoring the tests.
@swellaby/core-collaborators What do yall think?
This one is on me. VSTS task projects need npm scripts/configs/code updated so that the core transpile/lint/test tasks will pass in new projects
self explanatory
Extend the ESLint rules configuration (especially now that JSHint has been removed) to include all of the rules not covered by the ESLint:Recommended set
need to add start script to express generator
We've made a number of changes to the content/structure/etc. of projects that are scaffolded by the generator. Need to update the documentation accordingly
The current scaffolding configuration sets up the project to retrieve typedefs using Typings which has recently been deprecated. Typedef files now live in the npmjs registry (under the scope @types), so the respective scaffold components need to be updated to reflect this.
Thinking it would be good to have a script (preferably an npm script, otherwise sh & bat) to setup the development workspace
This one is on me.. while make updates to the template gulp-config.js I did some careless copying & pasting from the codebase of the generator itself that invalidates some of the gulp settings in generated projects. Fix & new version coming shortly
Steve showed me that you can hide the transpiled *.js*
in VS Code
I want to verify that this does not impact the debugging experience and if it does not go a head and add this to our default vscode config for users.
@calebcartwright Thoughts/concerns?
We should update the contribution docs to request users include the version of the generator itself when opening an issue (https://github.com/swellaby/generator-swell/blob/master/CONTRIBUTING.md#reporting-issues).
Getting the version of a globally installed yeoman generator is unfortunately a little more complicated than a standard global module so we should also provide info, commands, or a script for users.
Complete all scaffold content for the VSTS Task project type
Should we have the generator leverage npm's shrinkwrap for the scaffolded projects? I'm leaning towards no (current state), but we should make a decision on it prior to 1.0 release
The pros I see for shrinkwrap:
The major con I see is that it makes dependency management a real pain. We will have to very consciously follow and update package versions or do a lot of back and forth removal/recreation of the shrinkwrap file
I received an error after running the generator and specifying the 'Express API' project type. The output was: ......
npm install is failing on certain Linux environments with limited memory, specifically <= 512 MB (think ec2 T2.nano, raspberry pi, etc.) this is a known issue with npm on these types of low memory environments when there is a large dependency tree (as is the case with the generator-swell codebase).
I think a lot of it may be due to the git-commit hook module we are using, so will start by reviewing alternatives
The intent of this issue should be fairly self-explanatory.
The question/discussion aspects of this I imagine will be focused on which CLI mechanism(s) should be scaffolded. Shall we use:
I'd vote for commander as it adds some nice features with ZERO dependencies
All platforms/versions
Steve has figured out why the debugging of TS on the node side isn't working (caused by a bug in the configuration of gulp-sourcemaps). Opening this issue to track that fix
Let's enhance the generator's support for adding git hooks to generated projects.
Here's an example of the prompt flow (with option A for the hook config):
Would you like git hook support in your project? (y/n): y
(user affirms)
Do you want me to add the commit-msg hook? (y/n): y
(user affirms)
Do you want me to add the pre-commit hook? (y/n): y
(user affirms)
Do you want me to add the pre-push hook? (y/n): n
(user declines)
And the generator would drop a husky file into the project that has the hooks setup with some default values for the hooks the user specified:
hooks: {
"commit-msg": "commitlint -e $GIT_PARAMS",
"pre-commit": "npm run lint && npm test"
}
For option B the flow could look something like:
Would you like git hook support in your project? (y/n): y (user affirms)
Do you want me to add the commit-msg hook? (y/n): y (user affirms)
What would you like to run for your commit-msg hook? (list choice)
> commitlint (user selects commitlint option)
> foo
Do you want me to add the pre-commit hook? (y/n): y (user affirms)
What would you like to run for your pre-commit hook? (list choice)
> lint (user selects lint option)
> test
> lint and test
Do you want me to add the pre-push hook? (y/n): n (user declines)
And the generator would drop a husky file into the project that has the hooks setup with based on what the user specified:
hooks: {
"commit-msg": "commitlint -e $GIT_PARAMS",
"pre-commit": "npm run lint"
}
For option C:
Would you like git hook support in your project? (y/n): y(user affirms)
What would you like to run for your commit-msg hook? (list choice)
> nothing
> commitlint (user selects commitlint option)
What would you like to run for your pre-commit hook?
> nothing
> lint
> test
> lint & test (user selects lint & test)
What would you like to run for your pre-pushhook?
> nothing (user selects nothing)
> lint
> test
> lint & test & coverage
And the generator would drop a husky file into the project that has the hooks setup with based on what the user specified:
hooks: {
"commit-msg": "commitlint -e $GIT_PARAMS",
"pre-commit": "npm run lint && npm run test"
}
@swellaby/core-collaborators - test
Currently, the generator automatically adds a git pre-commit hook via an npm library. However, as this library is being installed it checks for a git repo in the local directory. This will work fine provided that the user has done a git init or clone in the cwd prior to executing the generator, but otherwise a warning is displayed and the hook is not installed.
As a short-term tactical solution we can display a notification to the user so that they know they need to run npm i
after they have created a git repo. The strategic solution should provide optional support to create the git repo as part of the generation process
Currently we populate the name & description fields of the package.json.
Here are the prompts provided by npm init:
name: ()
version: (1.0.0)
description:
entry point: (index.js)
test command:
git repository:
keywords:
author:
license: (ISC)
I think we should add prompts for author and license.
I think we can default the values of some of the other fields and no ask about them in the generator.
Thoughts?
Should build out some real docs on contributions (both PRs and opening issues), at least something more than my simple sarcasm currently in the contributing.md file :)
I just ran the generator and scaffolded a new VSTS Task project type, and somehow the jshint files (.jshintrc and .jshintignore) were added to the new project. I'm not really sure where it came from given the current codebase (and content of the files) but just want to ensure we didn't miss something when we removed jshint from the generator as part of #38.
Maybe it is coming from an extension on VS Code? @beverts312 have you seen this in any of your projects?
Setup the various gulp components needed for managing the new suite of component integration tests
The Codeclimate scan is currently failing.
We had previously marked the codeclimate exclusion fingerprints in the .codeclimate.yml file, however, the recent name changes to the directories have invalidated those fingerprints.
Opening this to remind myself to re-generate the relevant fingerprints to disable the false-positives that codeclimate is flagging right now
Refactor the generator itself to be written in typescript
@swellaby/core-collaborators
Do you guys see any problems with targeting ES6 instead of ES5 in the boilerplate tsconfig?
Then we could drop q from the VSTS generator and use native promises instead
Include an extensions.json file to the template content scaffolded by the generator
See relevant discussion on #9
I was thinking about adding support to optionally add VS Code files (to the express generator only to start with) so that user could have preconfigured shortcuts for building, debugging etc.
Any thoughts on if we should either:
?
make me a sandwich
I think it is fair to say at this point that the support for the front end project types (Angular, Aurelia, etc.) won't be in the 1.0 release, but what about the CLI project type?
It is the only type that exist in the currently displayed prompt options that is 100% empty. Will either need to implement it or remove it from the list (which entails updating the corresponding tests)
We are already grabbing the description of the app, we should pre populate the generated readme with this info as well
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.