Lerna, conventional commits and long term support releases - javascript

We have a number of packages in a monorepo, managed by Lerna and with mandatory conventional commits. While everyone's on the same page at the HEAD of master/latest version, things work great. But we now have a need for creating long term support releases, i.e. a major release that we keep backporting fixes to.
How is this supposed to work with Lerna? E.g.
Say I have a#1.0.0 and b#1.0.0 and b depends on a.
I make a breaking change to a and publish giving me a#2.0.0 and also b#1.0.1 due to the version bump.
I discover a bug in a, fix it on master and publish which creates a#2.0.1 and also b#1.0.2.
I create a branch from point 1 above and backport the fix (for purposes of long term support). When I publish it correctly tries to create a#1.0.1 but fails when trying to create b#1.0.1 since that version already exists.
Any ideas?

Related

javascript localeCompare return different value on browser as comparing to my local testing

I have the following code executed:
var eng = 'image'
var chinese = '影像'
console.log(eng.localeCompare(chinese),"zh-hant")
on my browser console, the result is 1
But when I run npm test to execute the above code, the result is -1
My questions are:
What makes the code return different value?
How can I fix this unstable code?
I think you are trying to compare english language with chinese one. So, I suggest, you should use Collator when needed. Most modern browsers are supporting it
Collator will sort in almost any language you can think of and has numerous options for customizing sorting by accent marks, capitalization, etc.
This compare link can help you understand how to compare non-english strings in Javascript
The one you run in a browser (say Chrome) has better i18n support. And when you run it with npm test, you are dealing with node.js, most likely a version prior to v13, with which only the locale data for en-US is available by default.
Meaning the option you passed to localeCompare, in your case, "zh-hant", silently falls back to en-US, leading to the different behavior in your question.
Source: Browser compatibility MDN
The fix?
The easy path
Upgrade your node.js to a version later than v13. Then you have full ICU (locale) data available, meaning you will have the same result with the browser.
The hard option:
If the upgrade is not an option, you will need to do this the hard way. Here are some links to start:
Here you can install full icu
https://github.com/unicode-org/full-icu-npm
Provide icu data at run time https://nodejs.org/docs/latest/api/intl.html#intl_providing_icu_data_at_runtime

Building Chrome Extensions on Existing Production React Websites

Background: I've been developing a bunch of browsers extensions on production sites (Yelp, Zillow, Trulia, Reddit) which use react. I've yet to take a course on React (I'm planning on doing it) but my questions are:
How stably named are the classes in production react sites (many of the classes have weird numbers and letters appended) and if they are not stable, how often do they change and is there any way to get a more stable selector for these types of items?
When classes are completely non-human readable, is there any way to view the class name in a more human readable format? e.g. <div class="_2jJNpBqXMbbyOiGCElTYxZ">
I'd hate to build these extensions and have them break whenever there is a minor release (I know they will break as the site is significantly updated but would prefer if they were stable for minor releases).
Example: Targeting a span like this
<span class="lemon--span__373c0__3997G text__373c0__2Kxyz reviewCount__373c0__2r4xT text-color--black-extra-light__373c0__2OyzO text-align--left__373c0__2XGa-">865</span>
with a queryselection like this:
const ratingCountTarget = result
.closest('.mainAttributes__373c0__1r0QA')
.querySelector('.reviewCount__373c0__2r4xT');
There's no way to get the original names and nothing precludes the site developers from updating the random parts any day or several times a day so find a way to not depend on the exact names.
Try finding the non-randomized attributes
Use relations between elements (combinators)
Use partial matching like foo.querySelector('[class*="reviewCount"]')
And get ready to having your extension inevitably break even if only occasionally.

efficient search in mongodb v2.4

I'm using version 2.4 of mongodb which is working fine for my needs, except one thing, i.e. searching as it doesn't support some advanced options like $search. So, is there a way to implement that kind of searching in v2.4. The reason i'm sticking to older version is because i don't want to lose any of my data by upgrading and also i don't want to stop live mongo server.
The result i want should be something similar as this query's result:
db.data.find({$text: { $search: 'query' } }, { score: {$meta: "textScore" }})
This query is working fine for latest versions of mongoDB. And also if you people suggest me to use the latest version, please provide some references which can help me safely upgrading mongodb.
This is a little bit of a catch 22, introduced mainly by text search capabilities being considered "experimental" in earlier versions. Aside from being in an earlier development phase, the implementation is entirely different due to the fact that the "whole" query and index API has been re-written for MongoDB 2.6, largely in order to support the new types of indexes available and make the API for working with the data consistent.
So prior versions implement text search via the "command" interface directly and only. Things work a little differently and the current "deprecation" notice means that working in this way will be removed. But the "text" command will presently still operate as shown in the earlier documentation:
db.data.runCommand("text", { "search": "query" })
So there are limitations here as covered in the existing documentation. Notably being that the number of documents returned are those contained the "limit" argument to that command and there is no concept of "skip". Also that this is a "document" response and not a cursor, so the total results cannot exceed the BSON limit of 16MB.
That said, a little off topic but consider your MongDB 2.6 deployment scenario, and mostly on the following.
Future Proofing. In the earlier forms this is an experimental feature. So any general flaws and problems are not going to generally be "backported" in any way with fixes while you hang on to the version. Some may, but without a good reason to do so this mostly wanes over time. Remember this is "experimental" so due warning was given about use in production.
Consistency/Deprecation. The API for "text" and "geospatial" has changed. So implementation in earlier releases is different and "deprecated", and will go away. The right way is to have the same structure as other queries, and consistently use it in all query forms rather than a direct command.
Deployment. You say you don't wan't to stop the server, but you really should not have one server anyway. Apart from being out of the general philosophy of why you need MongoDB anyway, at the very least a "replica set" is a good idea for data redundancy and the "uptime" of your application. Removing a single point of failure means that you can individually "bring down" discrete nodes and "upgrade" without affecting application downtime.
So that strays "a little" off the programming topic, but for me, the last point is the most important. Better to make sure your application is without the failure points by building this into your deployment architecture. This then makes "staying ahead of the curve" a simpler decision. It is always worth noting the "experimental" clause with technologies before rolling out to production. Cover your bases.

PouchDB + Conflict Resolution

I have a really simple question about hard topic:
How does conflict resolution work in PouchDB?
I looked at the documentation, as well as quickly googling, but it didn't help. So, how to do I handle conflict management in my application which is using PouchDB?
Here's how you do it in CouchDB, which you can directly translate into PouchDB terms since the APIs are exactly the same.
You fetch a document, using conflicts=true to ask for conflicts (get() with {conflicts:true} in PouchDB):
http://localhost:5984/db1/foo?conflicts=true
You receive a doc like this:
{
"_id":"foo",
"_rev":"2-f3d4c66dcd7596419c76b2498b3ba21f",
"notgonnawork":"this is from the second db",
"_conflicts":["2-c1592ce7b31cc26e91d2f2029c57e621"]
}
There is a conflict introduced from another database, and that database's revision has (randomly) won. If you used bi-directional replication, both databases will provide this same answer.
Notice that both revisions start with "2-." This indicates that they are both the second revision to the document, and they both live at the same level of the revision tree.
Using the revision ID, you fetch the conflicting version (get() with {rev=...} in PouchDB:
http://localhost:5984/db1/foo?rev=2-c1592ce7b31cc26e91d2f2029c57e621
You receive:
{
"_id":"foo",
"_rev":"2-c1592ce7b31cc26e91d2f2029c57e621",
"notgonnawork":"this is from the first database"
}
After presenting the two conflicting versions to the user, you can then PUT (put()) a third revision on top of both of these. Your third version can combine the results, choose the loser, or whatever you want.
Advanced reading:
The CouchDB docs on conflict resolution
The CouchDB wiki page on conflicts.
Understanding CouchDB Conflicts by Jan Lenhardt

Refactoring with emacs while editing javascript

Hi so I am writing a lot of server side javascript and I would like the ability to refactor while editing with emacs. Is this possible? Thanks!
By refactor I mean like how in eclipse while editing Java you can refactor one variable called for example "variableOne" into "variable1" and now all other 15 times you wrote "variableOne" becomes "variable1".
Probably the most sophisticated JavaScript refactoring library for Emacs is Magnar Sveen's js2-refactor. Its list of supported refactorings includes
rv is rename-var: Renames the variable on point and all occurrences in its lexical scope.
which sounds a lot like what you're looking for. It also supports a number of other very useful common rafactoring actions.
Assuming you're on Emacs 24, I recommend installing it using the MELPA repository. If you're still on Emacs 23 you'll have to upgrade or manually install package.el before you can MELPA.
If you are looking for just renaming variables, you might also want take a look at tern. The advantage it has compared to js2-refactor (which I use too) is that it has a concept of projects so you can rename a certain variable across multiple files in a project. It also provides other features like jump-to-definition and auto-completions (which are quite accurate).
Here are some general options for renaming a variable
1) Multiple cursors - It has a useful command mc/mark-all-like-this-dwim, which marks all the occurences of the selected text in current context you can then edit all the occurrences simultaneously.
2) Wgrep - This package enables one to apply changes done in grep buffer to respective files. This is useful when I have to replace a word across many files, in such situations use rgrep to search the word in multiple files. Then enable wgrep in the resulting grep buffer, mark the word to replaced with multiple-cursors (you can also use query-replace), make the changes and then do wgrep-save-all-buffers and all my changes are saved!
Your question seems to be more about renaming variables than about refactoring in general. The two places to start for information about using Emacs to rename parts of your code are these:
Emacs Wiki Search and Replace category page. This includes search-and-replace across multiple files (e.g. of your project).
The Emacs manual: use C-h r to enter the manual from Emacs.
Then use hit the key i to look something up in the index (with completion):
i search and replace commands takes you to the section about replacement commands.
i search and replace in multiple files takes you to the section about Searching and Replacing with Tags Tables.
For Emacs support for projects, see the Emacs Wiki Projects category page.

Categories