Create a base backend package with all the configuration files

[philippemiguet]

Followed this awesome guide: https://itnext.io/step-by-step-building-and-publishing-an-npm-typescript-package-44fe7164964c

I initially worked on creating a new package for adding tags to Datadog spans for our APIs, but then I quickly was slowed down by the lack of examples regarding how to create a package with all the base configurations: eslint, prettier, ts, jest, npm publishing.

So, I decided to create this base package that we can duplicate manually when building new packages: in the future, we can move it to some command-line tool 😉

@CoxyBoris @msanroman (cc @esclapes @MayaUribe), for the eslint/prettier and TS, I've used a mix of what was defined in engage/core/sp + frontend + this PR: https://github.com/bufferapp/buffer-standards/pull/5/files.

I think what I have here may represent our Buffer standard. How do you feel about taking these files and promoting them as standards in #5?

[philippemiguet]

This does not work as expected 🤔 It does not create a commit, and also with a repo with several packages, how will tags work?

[CoxyBoris]

hmm it should tag with the version defined in version for each individual package (each package should have it's own package.json). Shall we have a script to run npm publish here ? 🤔 I'm not sure to understand the meaning of postversion here

[philippemiguet]

Yeah, from this blog post, it is supposed to commit and push to GH automatically. But, it may be missing the git commit command.

[philippemiguet]

Any thoughts on the author? I remember Harisson used to put his own handle for instance. I feel like there will be several authors since the packages will evolve. Do we have an engineering handle?

[CoxyBoris]

Good one - I don't think we have an Engineering handle. However Buffer engineering sounds good to me 😄

[msanroman]

This handle comes from the local npm config if it's set, so not sure if we can really default it (not sure if that's an issue either) :)

[CoxyBoris]

Thanks for working on this @philippemiguet ! To me that's a really great starting point. Sounds good to me to apply the changes in #5

[CoxyBoris]

Good one - I don't think we have an Engineering handle. However Buffer engineering sounds good to me 😄

[CoxyBoris]

hmm it should tag with the version defined in version for each individual package (each package should have it's own package.json). Shall we have a script to run npm publish here ? 🤔 I'm not sure to understand the meaning of postversion here

[MayaUribe]

This is so helpful to have over here @philippemiguet! Is this something you think all other backend repos should apply as well at some point?

[philippemiguet]

@MayaUribe, yes that's the goal of the initial #5 PR that Mike started a few months back: to create packages with eslint/prettier/tsconfig for all repos to use them.

Mike's PR never got merged due to pending discussions, my proposal is to take the file from my PR, put them in Mike's, and merge it. Then, updating this PR to fetch the config for the npm package. Then, we can move all backend to use the config from our buffer package instead of having to define them manually.

I hope this brings clarity 😄

[esclapes]

@philippemiguet is the idea that this is a published package that we install or are these template files to be copy pasted?

It wold be great to add to the README some instructions about how to use it.

also with a repo with several packages, how will tags work?

In order to managing multiple independent packages on a single repository we would need to set up a mono-repository. Tools like rush, lerna or changesets can help you with that.

I originally expected this buffer-standards to be a single package similar to standard/eslint-config-standard, which bundled a mix of our pick of standard and prettier configuration.

If we are extending this scope to include other packages (i.e. the tracing wrapper) and other configurations like a tsconfig base config, we might need to take some time and consider what mono-repository approach we want to use.

[philippemiguet]

Hey @esclapes great thoughts!

is the idea that this is a published package that we install or are these template files to be copy-pasted?

I thought to be copy-pasted, but mainly because I don't know how a base package would work as a package 😄 I thought then in the future, we could use this with a generate package command instead of copy-pasting.

In order to managing multiple independent packages on a single repository we would need to set up a mono-repository. Tools like rush, lerna or changesets can help you with that.

Yes, great point. I kept the scope focused on my task here, but wanted to bring that topic tomorrow in our WG sync. If we decide to use it as a mono-repo for our packages, then we will want to invest in those tools and make sure we have a neat process to run tests, code climate, and publish packages.

[msanroman]

Hey @philippemiguet! So cool to see some momentum going on in this repo 🥇

I'd love to understand this one a bit more, though. How do you foresee us using this? It feels like it's setting up a boilerplate project, a la create-react-app and others like that. If so, the best usage would neither be copy&paste (since the potential of leftover attributes in the package.json is high) nor installing it as a dependency (because we don't want this as a wrapper, and more as a foundational code to start working on top of).

If that's the case, I'd advocate for rather than having this, creating a script that can be executed through npx that sets the right files and installs the right dependencies. This one can help as a source of inspiration.

[philippemiguet]

Hey @msanroman, yes it's a boilerplate for future package development. When I had to write the package for #10, I've lost a lot of time figuring out the config files, setting up Jest, and the right commands to publish to npm. I feel like we can help engineers by having a blank package with all the minimal required setup: eslint, prettier, tsconfig, jest, code climate.

And, yes, I agree the ideal will be to use npx instead of copy-pasting. I looked into it, but it grew the scope of my initial task: writting a library. This base-backend-package felt like a good start documenting what the output of npx should look like.

td;dr; I agree next step is to remove this folder and replace it with a npx script

[msanroman]

This base-backend-package felt like a good start documenting what the output of npx should look like.
td;dr; I agree next step is to remove this folder and replace it with a npx script

Sounds great to me, I would add then a mention on the README that this is intended to use as a source of documentation / copy and pasting and that it should be deprecated soon because we'll introduce that script!

🚀

[philippemiguet]

Thanks Mike! I've added that to #10 as I will close this PR and merge the other one with both packages to main.

Closing in favor of #10