chiubaka / generator-chiubaka-typescript-package Goto Github PK

Not clear on exactly which generator should have responsibility for this. Maybe the TsConfigGenerator? But that also seems weird.

Good to set up sensible defaults ecosystem-wide!

• Enable ECMAModules in jest
• Enable module: "esnext" in tsconfig (copy this modification over to chiubaka/tsconfig)
• Refactor code to avoid use of __dirname
• Re-enable unicorn/prefer-modules in linting configs

Similar to what I was seeing in #6, the "Tests" tab in CircleCI stopped working again :/.

I think it might be a change I made from ./reports/ to ./reports in the CircleCI configs? Not sure.

Just saw these generated by CircleCI in chiubaka/circleci-orb and I think this is super cool. Could be a useful way to standardize labels across repos.

This is causing CircleCI builds to fail even though the initial publish job succeeds. Example CircleCI Job.

The problem is explained in this StackOverflow post. Basically, publish is a reserved script name.

Run yarn tsc and check for output in the dist for with valid .js. Maybe even run Jest on the generated tests.

Ideally run linting pre-commit and testing pre-push.

shinsoku:generator-typescript-package dchiu$ yarn
➤ YN0000: ┌ Resolution step
➤ YN0002: │ generator-typescript-package@workspace:. doesn't provide @types/node (p70791), requested by ts-node
➤ YN0002: │ generator-typescript-package@workspace:. doesn't provide mem-fs (p4cb9a), requested by yeoman-test
➤ YN0000: │ Some peer dependencies are incorrectly met; run yarn explain peer-requirements <hash> for details, where <hash> is the six-letter p-prefixed code
➤ YN0000: └ Completed
➤ YN0000: ┌ Fetch step
➤ YN0018: │ @types/yeoman-environment@npm:2.10.7: The remote archive doesn't match the expected checksum
➤ YN0000: └ Completed
➤ YN0000: Failed with errors in 0s 204ms

Happening after merging of #5. Blocking development off of master since I can't seem to properly install new dependencies??

Make sure code written for the generator is, itself, clean and obeys all Chiubaka Technologies linting rules.

• Create CircleCi config
• Create .npmrc with template for publishing

Potentially makes some items in #37 obsolete.

See CircleCI Context Docs for more info.

Would need to update the generated .circleci/config.yml to use the context, but after that it's possible that jobs could just work out of the box!!

I should try to keep things further up from assuming that Circle is the provider lower down!!

Potentially programmatically create the GitHub project for the generated project as well?

After attempting to install this generator globally from published npm package, yo doesn't seem to pick it up so it cannot be used.

Would be great to have a standardized set of configs and for this package to consume those. Will also help with the tsconfig.json generation step of #3.

New package should have:

• TypeScript configuration
• package.json
• .gitignore

Seems like this currently isn't happening based on artifacts in the generated project on CircleCI.

Weird because we're expecting this to be exposed based on jest-junit configuration in package.json.

This will complete #66, which actually wasn't done with the merging of #73.

This should likely be moved to the ESLint config / plugin project once it's created.

After adding eslint-plugin-yml, I'm unfortunately not seeing the YAML errors show up in the VSCode UI even though eslint correctly picks them up from the command line.

Seems like I'm not the only person to have seen this, but this particular issue was closed because no example repo could be made: microsoft/vscode-eslint#997

Generated modules should have a similar setup to #12.

Would be nice to make sure tests and other checks are clearing before merge, and the generator should dogfood the scaffolding it's creating for other packages.

Generated package should have a setup similar to the one created in #1. This should potentially use something from chiubaka/eslint.

I'm exploring the usage of Code Climate. Quality is free for small teams!

Curious what this is. Would like to pilot it to find out! Appears free for small teams.

When the generator is published, we should publish to NPM as you would expect.

However, we should also run the generator with a standard set of options, output that to a submodule, then commit and push updates to that submodule with a message matching the current version of the generator.

#44 likely needs to be completed before this can happen. Standardized configurations for generated packages can be stored as YAML and consumed by the non-interactive mode of the generator.

This is strictly better than relying on string matches in the file

Seems like the templates directory for the gitignore directory is not getting copied over. Unclear why.

Since I recently made Jest responsible for its own .gitignore entries in #57.

Artifact from the v0.2.0 build shows now file names and an incorrect classname attribute template.

Discovered while attempting #68.

Add a basic testing harness for the generator itself so that we can verify its functionality continues to work as we upgrade and improve it.

Currently doesn't happen, and I'd like to establish this as a convention across the ecosystem.

I'm trying to write a TsConfig generator to resolve #3, and ESLint trips over TsConfigGenerator.ts with this error:

If I rename the file to something else I don't see this problem. Weirdly, if I run ESLint from the command line, it also doesn't trip over this file. It's showing in the VSCode UI, though, which is pretty annoying.

JSDoc has some uses like IDE support for @deprecated

Shouldn't be a hard fix. Make sure both the lint command and the .lintstagedrc.yml files support .md as well. Potentially also need to make sure tsconfig processes these files

Good to enforce sensible defaults ecosystem-wide!

Useful for CI and automation.

The root generator:

• Should read a YAML file from a location specified by a CLI option

All child generators:

• Should support a no-prompt mode where prompt answers are expected to be supplied as options or arguments

 FAIL  src/node-module/NodeModuleGenerator.test.ts
  NodeModuleGenerator
    ✕ creates a package.json file (280 ms)

  ● NodeModuleGenerator › creates a package.json file

    Cannot find module 'isbinaryfile' from '/Users/dchiu/Developer/generator-typescript-package/.yarn/__virtual__/yeoman-environment-virtual-159b0d0798/0/cache/yeoman-environment-npm-3.9.1-6ff00ff453-60a19b9962.zip/node_modules/yeoman-environment/lib/util'

    Require stack:
      .yarn/__virtual__/yeoman-environment-virtual-159b0d0798/0/cache/yeoman-environment-npm-3.9.1-6ff00ff453-60a19b9962.zip/node_modules/yeoman-environment/lib/util/binary-diff.js
      .yarn/__virtual__/yeoman-environment-virtual-159b0d0798/0/cache/yeoman-environment-npm-3.9.1-6ff00ff453-60a19b9962.zip/node_modules/yeoman-environment/lib/util/conflicter.js
      .yarn/__virtual__/yeoman-environment-virtual-159b0d0798/0/cache/yeoman-environment-npm-3.9.1-6ff00ff453-60a19b9962.zip/node_modules/yeoman-environment/lib/environment.js
      .yarn/__virtual__/yeoman-test-virtual-d24845de57/0/cache/yeoman-test-npm-6.3.0-cf0e4ba284-7d8e79fadd.zip/node_modules/yeoman-test/lib/index.js
      src/node-module/NodeModuleGenerator.test.ts

      at resolveSync (.yarn/cache/resolve-patch-46f9469d0d-5656f4d0be.zip/node_modules/resolve/lib/sync.js:111:15)

I have found that installing isbinaryfile as a dev dependency in my package resolves the error, but it feels like I shouldn't have to do that :/. Feels like yeoman-environment should be including isbinaryfile as a dependency so that it gets pulled in when I install yeoman-environment. I opened an issue with them to this effect: yeoman/environment#420

Tough to justify working on this, as I've found a workaround that doesn't involve a multi-line array, but I've found that it's surprisingly difficult to get the right formatting and indentation for a multi-line array of keywords in EJS.

There's some discussion of how includes don't respect indentation from the included file here, which is semi-relevant.

It's possible I just don't know all that much about EJS, but the one version of this that I was able to get working looked really bad in code, and just wasn't worth the trade-off. It felt like EJS wasn't respecting my indentation choices even inline, and I couldn't quite grok the pattern (or lack thereof) of indentation output based on the code I wrote.

I noticed that line length is not getting flagged and corrected in VSCode.

This could be part of the solution: https://github.com/prettier/prettier-eslint

Midana project likely already has a solution for this I can copy.

Choosing CodeCov because they're offering free unlimited usage for open source and a limited free plan for private repos.

Pricing for CodeCov is also more competitive for a small team ($10/mo vs $25/mo for Coveralls, though Coveralls comes with unlimited users at that price).

So we don't get false alarms.

For example, the NodeModuleGenerator should be responsible for the NPM shield and the CircleCiGenerator should be responsible for the CircleCI shield.

This would be nice because it means that subgenerators are, themselves, completely self-contained. If I don't run the CircleCiGenerator, no other generator is going to see anything at all related to CircleCI. There are a few exceptions since we globally expect there to be both a README and a .gitignore file, but for the most part this model makes sense to me.

I encountered some difficulty getting this to work properly. Specifically, I was finding that the NodeModuleGenerator would constantly fail to find the README.md file that should have been created already by the ReadmeGenerator that it was composed with.

Some logging did reveal that the ReadmeGenerator#writing method was being called before my attempts to write to README.md (note, though, that by default NodeModuleGenerator#writing appears to happen before its composed sub-generators, so I placed my write attempt in conflicts or install).

I kept getting that README.md does not exist. Weirdly, doing this.fs.exists("README.md") would return true, but this.fs.read("README.md") would throw the error.

I did some searching around in the Yeoman docs and in the underlying mem-fs-editor docs and found that this functionality should be working because mem-fs-editor seems like it should be checking its in-memory files before going to disc and because Yeoman claims to be sharing the mem-fs-editor instance across all subgenerators.

Ultimately, I gave up on getting this to work and decided to move the shield generation into ReadmeGenerator, which I don't love.

• Should include instructions to complete set up of git repository
• Should include instructions to complete set up for CircleCI
• Should include instructions to complete set up for CodeCov
  • Add CODECOV_TOKEN env var to CircleCI

Would be great to have this out of the box!!

This is the point we're at in the chiubaka/circleci-orb. The generated package is expected to have a test:ci command, but I haven't quite gotten that far yet.

Time to fill it in!!

Blocking chiubaka/circleci-orb#1 since the CircleCI test command for installing yarn packages won't run without an existing lock file.