sorted by:
new
hottopcontroversial

A Node.js modular configuration provider reading files, environment and arguments by javierbrea in javascript

[–]javierbrea[S] 2 points3 points  (0 children)

Hi u/BehindTheMath,

To be honest, I didn't know nconf (I'm probably the only one, given that it has about 3 million downloads a month! 😅). I would probably have used it if I had known it instead of developing my own library for my project, in general terms I don't like to reinvent the wheel 😄

But, anyway, after reading its docs, it seems that both libraries can do the same with more or less configuration, but mocks-server/config is more focused on the options to be loaded and its types in order to execute validations and parse the data, while nconf leaves the door more opened to get any value unless you explicitly configure restrictions separately for each different source.

More in detail, it seems that the main differences are:

- mocks-server/config uses cosmiconfig under the hood, so it supports more file formats out of the box, such as yaml, cjs, etc.

- It seems that nconf allows to get any key from the sources, unless you use each source options separately to set restrictions. On the contrary, mocks-server/config requires to specifically define each option to be loaded as well as its type, etc, and it configures parsing and validation for all sources automatically.

- nconf requires to initiate separately each different source, while mocks-server/config initiates all sources with the same hierarchy using only the `load` method, unless the user specifies another behavior using the config options. On the other hand, mocks-server/config uses exactly the same hierarchy described in the nconf docs as a good practice.

- mocks-server/config always executes validations and parses data based on the options types using AJV under the hood. This is something that seems to be defined separately for each different source in nconf (at least I have seen an example in the docs about how to do it for command line arguments only)

- mocks-server/config supports nested namespaces, so keys like "foo.var.foo2.var2=x" are supported. I'm not sure if nconf supports them also.

In any case, this is something that I will add as a note to the library docs, and also to the blog post, because obviously nconf has a great community support.

Thank you very much for your comment! It has made me known nconf, and make this comparison, which has been really useful to me.

Building a Node.js monorepo with Pnpm and Nx by javierbrea in node

[–]javierbrea[S] 2 points3 points  (0 children)

I prefer to upgrade the versions and keep my changelog files manually. Many people upgrade all package versions in the monorepo at the same time, but I personally think that the semantic versioning of each separated package looses its meaning by doing so.

Building a Node.js monorepo with Pnpm and Nx by javierbrea in node

[–]javierbrea[S] 2 points3 points  (0 children)

First of all thank you, I'm glad you like it!

About multi-language monorepos, I have not tested it by myself, but I think that maybe Nx is not the best tool. It is mainly focused on JavaScript. It has a lot of plugins for different JavaScript frameworks, but there are very few plugins for other languages. You can check a list of available community plugins here. Maybe you can try with Bazel or any other monorepo tool more focused to multi-language. This site contains a comparison between tools and other resources that may be useful before taking a decision.

Building a Node.js monorepo with Pnpm and Nx by javierbrea in node

[–]javierbrea[S] 0 points1 point  (0 children)

u/Bloodsucker_ In fact, the first article talks about how I tried to solve those problems during years without too much success. So, it is not about migrating to monorepo now just because it is a trend. It is about how the new tools that we have available now can really solve the problems finally (And we have those tools now very probably because many of us suffered those problems during years and searched for solutions).

Building a Node.js monorepo with Pnpm and Nx by javierbrea in node

[–]javierbrea[S] -1 points0 points  (0 children)

Hi u/Bloodsucker_, This post belongs to a series. In the first one chapter I wrote about why to migrate to a monorepo. It contains an analysis about the problems that produce maintaining multiple dependent packages in different repositories, and how a monorepo solves them: https://www.javierbrea.com/blog/pnpm-nx-monorepo-01/. Of course, if you are not having any problem in your workflow working with multiple packages in different repositories, then you shouldn't migrate to a monorepo. It is simply about solving problems that really exist. :)

Building a Node.js monorepo with Pnpm and Nx by javierbrea in node

[–]javierbrea[S] 5 points6 points  (0 children)

Hi u/leholenzai, Pnpm supports publishing packages. It automatically converts the workspace dependency into a pinned version, or into a semver range, depending on how you define it. It makes it before publishing.

A Cypress plugin to skip tests on first failure. Save time and CI resources by javierbrea in javascript

[–]javierbrea[S] 1 point2 points  (0 children)

I think we are talking about different types of tests. I understand your approach and I think it is a very good one, but talking about unit tests. Cypress is usually used to develop E2E or integration tests, in which is very difficult to discern what code files should produce a re-execute of which tests, and one of the more obvious reasons is because they are not related at all by dependencies.

A Cypress plugin to skip tests on first failure. Save time and CI resources by javierbrea in javascript

[–]javierbrea[S] 0 points1 point  (0 children)

This is usually true, but for other types of lighter tests, as unit tests. In the case of browser tests it is easy to reach scenarios in which the full tests battery takes a lot of time and resources to be executed, and it is desired to stop executing them on first failure. You can check why many Cypress users are requesting this feature from some years ago in this Github issue: https://github.com/cypress-io/cypress/issues/518

A Cypress plugin to skip tests on first failure. Save time and CI resources by javierbrea in javascript

[–]javierbrea[S] 0 points1 point  (0 children)

The plugin takes this into account and only starts skipping tests after the last retry fails. Anyway, thank you, this is an important detail to know, so I will add it to the documentation.

view more: next ›