swellaby / generator-swell Goto Github PK

View Code? Open in Web Editor NEW

9.0 5.0 2.0 2.49 MB

Highly opinionated Yeoman generator for various types of Node.js, Angular & Aurelia projects with TypeScript.

License: MIT License

JavaScript 6.11% Shell 0.48% TypeScript 93.37% Dockerfile 0.04%

status-badge yeoman-generator typescript typescript-generator generator yeoman

generator-swell's People

Contributors

Stargazers

Watchers

Forkers

calebcartwright skjr001

generator-swell's Issues

Broken SonarQube badges

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:

Sonarcloud integration
Slack integration
Codeclimate integration
Coveralls integration
Snyk integration
Ability to run tests against multiple versions of node (i.e. via something like nvm)
Ability to run tests against multiple platforms/distros (CircleCI 2x lets you bring your own Docker images for builds, whereas I believe TravisCI only allows you to choose between a couple versions of Ubuntu)

**** 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

CI Enhancement - Appveyor

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.

gitignore not included with package on npmjs

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

Add TSLib to TypeScript Compiler Options

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

Linters ESLint vs. JSHint vs. Both

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:

JSHint has been a real PITA to work with the types of content in the generated projects (TypeScript async/await, ES6 promises, etc.) In contrast, it only took a couple of minutes to update the ESLint rule configurations to account for this
JSHint used to contain more features (to support style checks for example) but that was deprecated in lieu of JSCS, which ultimately folded/merged with ESLint. ESLint today provides a one stop shop for what JSCS/JSHint paired together used to provide. With ESLint in place, our JSHint step is essentially just executing half of the ESLint rules twice
ESLint has some nicer mechanisms. For example in-line/in-file support to disable then re-enable a rule using the same global config values as opposed to JSHint which requires inline rule tweaks to reset the value of the rule in line.
ESLint has more flexibility in the configuration for warnings vs. errors etc.

Thoughts @beverts312 or anyone else?

Update prompts to support author

Update prompt configuration to include the following:

Author (for use in package.json as well as in specific contexts for certain project types)

Fix vscode tasks on Linux

Tasks are currently referencing cmd

Include TSLint rule extension for eslint

https://github.com/buzinas/tslint-eslint-rules/tree/master/src/rules

Packaged generator not scaffolding all files

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 not currently running against generator codebase

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

Add license to generator code

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?

Automated Functional Tests

@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?

Broken npm build script

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.

Add VS Code files/configuration to repo code

Add the same content for VS Code that has been added to the template content (#76 & #78) to the generator codebase

Add Aurelia project template

Refactor Tests

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?

Bug: Many scripts fail on scaffolded VSTS Task projects

node version: all
npm version: all
yo version: all
generator-version: 0.14.1-alpha, and possible previous
os: all

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

Setup Deployment Pipeline

self explanatory

Update ESLint Rules

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

Enable TypeScript debugging on generator code

Add the same fixes applied in #76 and #78 to the generator codebase

Express Generator missing start script but used by Dockerfile

need to add start script to express generator

Doc Updates

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

Upgrade scaffolded templates to get typedefs from npm registry

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.

script to setup dev environment

Thinking it would be good to have a script (preferably an npm script, otherwise sh & bat) to setup the development workspace

Bug: Gulp Config Incorrect

node version: all
npm version: all
yo version: all
generator version: ^0.12.0-alpha
os: all

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

Hide transpiled files in VS Code

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?

Update docs for contribution to include generator version

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.

Finish VSTS-Task Project Type

Complete all scaffold content for the VSTS Task project type

Shrinkwrap support?

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:

easier debugging/support since we will know the specific version of each package in the dependency tree for each version of the generator we release
could address the warnings currently displayed during an npm install of a generated project due to node-uuid being used somewhere in the dep. tree (not a direct dependency)

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

Error generating Express API project type (Good Issue Example)

node version: 7.7.2
npm version: 4.1.2
yeoman version: 1.8.5
generator-swell version: 0.9.3-alpha
OS: Ubuntu 16.04

I received an error after running the generator and specifying the 'Express API' project type. The output was: ......

Bug (intermittent) - npm install failure of generator codebase

node version: multiple
npm version: multiple
yo version: n/a
swell generator version: any/multiple
operating system: Linux

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

Add CLI project template

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:

basic process.argv[]
commander
yargs

I'd vote for commander as it adds some nice features with ZERO dependencies

Debugging TypeScript not working

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

New Feature: Extend git hook support

Let's enhance the generator's support for adding git hooks to generated projects.

Have the first/initial prompt ask the user if they want to include git hook support in the project
- This can either be a basic Confirm prompt type (y/n) or we could do a List prompt type with two options: one with text representing affirmation and another with text representing a decline (could introduce the cheeky message here)
If affirmative, we should then present the user with options for the 3 core types of client side git hooks:
- commit-msg
- pre-commit
- pre-push
For those specific hooks, we could either:
(A) present each of those 3 as a Confirm prompt, and then plug in our own hook script for the respective hook type with a pre-coded default value
(B) present each of those 3 as a Confirm prompt, and then for each affirmative, present the user with a follow up List prompt that allows the user to pick which script/validation they'd like to run (for example lint, test, code coverage, etc.)
(C) present each of those 3 as a List prompt where the list contains the set of validation scripts we can plug in for that respective hook that make sense as well as a skip/ignore/don't setup the hook option.

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"
}

git hooks aren't being created & request for generator to support git repo initialization

@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

Add License support like npm init Functionality

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?

Create Contributing guidelines

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 :)

JSHint files still being scaffolded by the generator

node version: 7.7.2
npm version: 4.1.2
yeoman version: 1.8.5
generator-swell version: 0.9.3-alpha
OS: Windows 10

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?

Gulp setup for component integration tests

Setup the various gulp components needed for managing the new suite of component integration tests

CI Bug - Codeclimate

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

Fix CI related service integrations

Refactor to Typescript

Refactor the generator itself to be written in typescript

ES5 vs ES6

@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

Add template for VS Code Extensions

Include an extensions.json file to the template content scaffolded by the generator

See relevant discussion on #9

VS Code Files

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:

Add Optionally
Always add
Never add