Uncaught DOMException: Failed to execute 'define' on 'CustomElementRegistry': this name has already been used with this registry
at http://127.0.0.1:8000/components/#polymer/polymer/lib/elements/dom-module.js:175:16
Tried deleting node-modules and package-lock and reinstalling did not work.
this error is due to a custom element tag-name being registered which is already registered; to fix simply check that an element by this name hasn't already been registered. This example solution checks to see if something is already registered using the existing API and if not, registers the given Class (inheriting from/extending HTMLElement--at some point):
customElements.get('the-element') || customElements.define('the-element', HTMLTheElement);
For more on the API see https://developer.mozilla.org/docs/Web/API/CustomElementRegistry
most/mature libraries address this problem and those that don't, or are mangled by package and build process complexities can have it pop up; in most cases either updating to a current version, migrating to Lit (https://lit.dev) or patching the problem somehow provides a path to a solution; note the simpler solutions are far easier to maintain--as can be seen in the conflation of npm, polymer over the actual error in the original question; the Polymer project became lit-html and LitElement, and recently rebranded as "Lit" (and still includes these lit-things). Professionally I'm migrating away from npm and Nodejs to Deno with the aim of generally resolve the many problems related to npm and tooling insecurity and complexity, however this answer provides a more direct solution (understand the problem and fix directly, or update to the relevant latest solution which includes this somehow).
Well, this worked for me, with no Typescript warnings,
if (!customElements.get('the-element')) { customElements.define('the-element', HTMLTheElement); }
Hope someone will find this useful.
Cheers.
It is unwise to use the answers above. You want it to fail! The reason being is that your NPM should be deduping duplicate packages, so the fact that you see a certain component being defined on the custom elements registry more than once is a crucial error that you need to debug why the same component is registered more than once.
How to debug, in short, go to your browser, inspect element, network tab, refresh, figure out which files are both registering the same element. Then check in the initiator to see which files are loading those files. Then you get a way better idea of why your app is not resolving the same import to a single place (your deduped dependency).
One reason why you might face this problem is due to semver. If you have multiple different major versions of the same dependency, NPM cannot just dedupe all of the installations to your root node_modules. How you solve this is up to you. Some people use npm-aliases for their different majors of a dependency, some people implement a plugin in their build-tool to resolve paths to a single installation, etc.
For people that can't use #jimmonts answer because the issue is in one of their dependencies you can use the following snippet:
This happens for us, because a package we are using defines an element. But this package is used by multiple apps. And these apps, wouldn't you know it, interact. So customElements.define('x-tag', className) gets called multiple times. And the second time it does, it crashes the app.
function safeDecorator(fn) {
// eslint-disable-next-line func-names
return function(...args) {
try {
return fn.apply(this, args);
} catch (error) {
if (
error instanceof DOMException &&
error.message.includes('has already been used with this registry')
) {
return false;
}
throw error;
}
};
}
customElements.define = safeDecorator(customElements.define);
I was getting the same error. You may not have the same issue as me but I thought I would drop my solution here just incase someone runs into the same issue in the future.
I had two modules that both imported the same custom element module, one of the was importing Module.js and the other module.js. Now the browser saw this as two separate files because URLs can be case sensitive, except my server saw this as one file because it is not case sensitive (express.js) or at least it was able to resolve the path to the correct file even with the incorrect case. And so the browser saw two "different" modules both defining the same custom element, but when I searched my source code only one file was defining the custom element.
I had this problem and found out that I was calling on my boundle.js file twice. Since I was using Webpack and HtmlWebpackPlugin, HtmlWebpackPlugin added the reference to my boundled file to my index.html file where I had already referenced it by hand.
I developed a solution, thats overrite the define with a precheck before define. It works fine for me, just ad the 2 lines into your index.js
customElements.defineclone = Object.assign(Object.create(Object.getPrototypeOf(customElements)).define, customElements);
customElements.define = (name, element) => customElements.get(name) || customElements.defineclone(name, element);
The parse4cn1 library works well with parse.com but it has some issues when working with Node 4.3.2 and parse-server open source. For example, when calling the ParseUser.signup() function, the "Invalid key name" exception is always happened. I tried to debug and figure out that the ParseCommand object should add the ParseConstants.CONTENT_TYPE_JSON to its header in order to make it can work. I don't why because it still works without doing this with parse.com.
Another issue is the ParseQuery.find() is always failed when using the ParseQuery.whereContainedIn(). The server exception is "ParseException [code=102, msg=Improper encode of parameter, cause=null]". I guess this issue probably regarding the parameter has the json format in this case as well but I don't know to to resolve it. Any advice is appreciate. Sidiabale, do you have any advice? Thanks!
These problems are solved in version 3.0 of parse4cn1. Apparently, Parse Server is stricter with the need to specify the content-type header so code that previously worked with Parse.com does not work with Parse Server. I've addressed these issues in the aforementioned release. Try again with version 3.0 and let me know if you encounter any issues.
I can't seem to find a solution to access a MySQL server from an Objective-C Mac OS project (which uses ARC).
I tried to use the MySQL framework that Sequel Pro provides, but that crashes (EXC_i386_GPFLT) my App whenever I just create a connection object:
SPMySQLConnection *conn = [[SPMySQLConnection alloc] init];
I don't know whether that is a bug in the framework or if I need to do something else in order to use it.
I tried a few other libraries (like MySqueakQl) but none of them are ARC compatible.
Also I tried to link to libmysqlclient.a directly, but if I copy that library into my project, I get a code signing error; if I just link to the .a in /usr/local/mysql/lib/, I get another error: dyld: Library not loaded: libmysqlclient.18.dylib ... Reason: image not found. I have to admit that I have zero experince with using third-party libraries (whether .a or .dylib) and probably didn't do it right.
I'm a bit surprised that there doesn't seem to be an up-to-date (read: working) solution out there. I know, consumer apps rather use Core Data, but I have to access out company database server.
Has anybody seen a solution (libary?) that works more or less "out of the box"? I'd be willing to pay for something that actually works.
A good tutorial on how to use .a libraries in Xcode projects that would also help me to understand where the dylib error comes from would also be very helpful.
Problem solved. I probably made some mistake when including the library.
The right steps to do this:
Drag the libmysqlclient.a library into your project window
Make sure you set Copy items if needed to Yes, and that it is added to your main target
Drag a folder containing the headers (found under /usr/local/mysql/include) into your project window
Again, make sure you set Copy items if needed to Yes and the correct target is checked.
Then:
#import "mysql.h"
- (BOOL) mySQLTest {
MYSQL connection;
mysql_init(&connection);
if(!mysql_real_connect(&connection,
[self.host UTF8String],
[self.user UTF8String],
[self.password UTF8String],
[self.database UTF8String],
self.port,
NULL,
0)) {
return NO;
}
// ... work with the DB
mysql_close(&connection);
return YES;
}
Works like a charm.
I have no idea why on my former attempts I got an error about the dylib; I never used it (only the static library).
The code signing issue may have been just a bug or one-time quirk in Xcode.
I'm trying to use Graphics32 package. Graphics32 was compiled and installed without any issue.
When I try to execute (debug) following code under C++ Builder XE3
TBitmap32* bmp = new TBitmap32();
bmp->LoadFromFile("d:\\sample.bmp");//This calls SaveToStream instead of LoadFromFile
...
it calls another member function SaveToStream which I can trace into and step while debugging until AV rises.
I have never encountered such behavior before.
Is there any compiler directive I'm missing or some workaround to make proper function call?
Update: I use the Graphics32 source from SVN. Everything works good if I use code prior to revision 2122.
I built a console app to find all the *.ts files in my project and then compile them using tsc.exe.
Everything was working fine, but as I converted my JavaScript files to TypeScript, I eventually ran into the following error:
ytsc.js(21053, 17) Microsoft JScipt runtime error: 'window' is undefined
Each time this happened when I was trying to extend window:
window['prop'] = "something";
I tested the code until I found the answer, which had little to do with my code...
The fault was my build tool.
I had declared the -e (execute) command line option when calling tsc.exe:
I did this because I thought I might add some automated testing code in the modules.
The cause for the error:
Most of my code is in functions.
However, there were a few places that I wanted to extend 'window' (for example if a built in function is missing from an old browser, I was shimming those calls). The code to shim the window object was running as the file loaded:
if (window.fun == null) {
window.fun = function(){...};
}
Anyway, because of the -e option, the tsc.exe was attempting to run the code (outside of a browser environment). This caused the above error.