I've been struggling and very frustrated because I can't find a way to make pickadate play well with browserify. I'm migrating a Backbone app from AMD but pickadate seems impossible to work with it. I must say that I began to use browserify recently so I'm not an expert but I could migrate the rest of my code without any major incident. Of course I'm open to receive some tips and references to master browserify :)
I have jquery and pickadate installed via npm and when trying to use pickadate I'm getting the classic error:
undefined is not a function
I used this way of requiring (note the use without assigning the require to a variable):
require("jquery");
require("pickadate");
I saw this on an answer here at stackoverflow (Requiring pickadate.js with Browserify) but it doesn't work in my case.
Any help or reference about where to find help will be pretty much appreciated.
The current version of pickadate as a module only exposes the instance of PickerConstructor but it doesn't expose DatePicker neither TimePicker so every time we try to instantiate a date picker or time picker we got the error undefined is not a function because neither of them have been loaded and so no jquery.extend invocation have been made to append them to the jQuery object.
What is needed is some kind of facade / wrapper to expose all the pickadate functionality out of the box.
For this I made some small changes directly to the pickadate code base. I added an index.js that works as the facade / wrapper for picker.js, pick.date and pick.time, allowing them to be used out of the box with Browserify by issuing the typical require('pickadate'). It doesn't need to be assigned to a variable since pickadate attaches itself directly to the jQuery object. You can check this gist with the index.js code I used
This change is a copy of the way the CryptoJS library by #evanvosberg exposes its different algorithms through the same pattern implemented in its index.js file.
The only additional change would be to modify the property main in pickadate package.json to point to index.js.
I've just send a message to #amsul, the pickadate author asking for the possibility of integrate this changes directly into the pickadate github repo.
I hope people trying to use pickadate with browserify can find this solution and stop getting frustrated trying to make them play well together!
Greetings to everybody!
Related
as shown below:
I don't understand why, the syntax and format is correct, it's extremely confusing.
I review my code carefully but can't figure out
this seems to be a bug with VS Code. This could be because VS Code is not updated, or an extension that is not supported anymore.
first, try ctrl + shift + p and running >Developer: Reload Window this should reload your current environment and the error should be fixed.
If that doesn't work, try a different extension. I currently use Vetur, and Prettier.
And don't forget to make sure your VS Code is up to date. go to the bottom left and click the settings cog, then check for update or updates.
My answer is, "Start from scratch, and record your steps." I'm happy to share my notes on what is presently working: https://github.com/TheAutomaTom/VsCodeSettings-Vue3
My personal machine had been in that spot for some weeks, so I took a step back and dump out your cornucopia of extensions and their dependencies.
Only run pertinent language services. This is a tall order given how much a Vue + Typescript + Tailwind on Vite app covers. I am suspicious of generalized HTML/CSS/JS packs though, because they may not be built to parse Vue SFCs. Every new release of a services intended for other frameworks, like Angular or React, are still possible culprits (and moving targets).
I gave up getting Prettier and ESLint on stable ground. For a non-workplace thing, I feel okay about that. You may be having issues with a global package, if you've been experimenting. I've tossed out a couple branches following different tutorials. I intend to revisit this one since it has some example projects: rvest.vs-code-prettier-eslint
I've noticed the Volar team seems to let oddities squeak out a little more frequently than I remember in Vetur.... but we love them just the way they are. Sometimes I downgrade just to check if I've gone crazy, yet.
When serving lit-element components with nollup then I keep getting the following error in the browser console that I am not able to track down:
toast-messages.js:56 Uncaught TypeError: modules[number] is not a function
at create_bindings (toast-messages.js:56)
at toast-messages.js:57
at Object.48 (toast-messages.js:365)
at create_bindings (toast-messages.js:56)
at _require (toast-messages.js:141)
at toast-messages.js:249
at toast-messages.js:251
Can anyone point me in the right direction? (I can share my rollup.config.js if required)
This error means that a module has been requested, but there's no module with the specified id (number) included in the bundle. This can happen for a variety of reasons:
There's a call using require passing an invalid id.
Passing a string or something other than a number into require.
Using a library that was compiled to CommonJS but was not transformed to ESM.
It's likely that you're missing the CommonJS plugin, or if you are, then the CommonJS isn't able to catch the require call and convert it. The latter can happen because of obfuscation in the library code. CommonJS plugins work by using static analysis. It would be very difficult for the plugin to transform the following:
var r = require;
r('my-library-code');
Without executing the code, it would be difficult for static analysis to track this. A best effort attempt can be made, but there will be always a situation where it could fail.
So here's the following steps you should take:
* Confirm that the CommonJS plugin is being used.
* If it is, check the file in node_modules for unusual patterns.
* If there is, file an issue with the CommonJS plugin maintainer and see if it's possible to solve, and if not, you might need to contact the maintainer for the toast-message library.
I do realise I'm posting this very late, but better to answer later than never! To avoid this vague error in the future, in 0.10.2 of Nollup I've added a user friendly error that list some things to check for.
Hope this helps!
Max, I want to update my extension to the new format, but I am running into issues with placement of custom code. It seems that the extension framework has been updated a lot since I added an extension 4 years ago. Is there a way to get better documentation on getting started with adding a extension? I am happy to help write up the documentation if you can help answer some questions that I think would help get people started. Let me know.
The only thing that really changed is that the scaffolder creates a webpack project for you. The extension registering procedure is the same: http://js.cytoscape.org/#extensions/api
For example, cytoscape( 'collection', 'fooBar', function(){ return 'baz'; } ) registers eles.fooBar().
I guess the main thing is that there are a lot more files than what the previous scaffolder generated, so it might be harder to find things. The layout output has lots of files, because it creates a skeleton impl for each of the continuous case and the discrete case.
The scaffolder isn't strictly necessary. You could use another build system (or none at all) as long as you call cytoscape(). For example, if you only care about publishing to npm for people who use webpack/browserify/rollup, then you could just use cjs require('cytoscape') to pull in the peer dependency. Exporting a register function is nice if you want to allow the client to decide the order of extension registrations with cytoscape.use(extension) (or extension(cytoscape)).
You're right that there should be some more docs on the output of the scaffolder. Maybe a summary of the files would suffice. We could add a tutorial in the blog later if need be. Both the docs and the blog just use markdown, so the content could go in either place.
I have a windows form application in which I'm attempting to utilize a plugin (class library). In the code I have it load the assembly from a dll file, which means I have not been able to debug. Furthermore I have not found out how to compile the library so I've had to use the debuged dll version for testing. I've run into a bug in which I create a new object and send that data through an interface to the plugin in an attempt to retrieve a blank slate group box from the plugin. However instead of reading the parameter as a new object i managed to step through the code once (don't ask me how, I don't know and I haven't been able to repeat it) and it appeared that the code was registering the parameter as "nothing" thus why I received a null reference error in the main program.
Is there a better way to debug this mechanism and find out where the problem is? Any ideas on what the problem could be. As I read over this is seems somewhat vague and I'm not sure how to describe it, but I'm willing to host a connect now meeting if anyone is willing to look at what is going on and I'm not making myself understood very well.
I'm not sure if I follow exactly what you're doing but I usually find that the best way to debug a class library is by in the solution for the class library I add a new project, either a WinForms one or a Console one, I then set this new project as the start up project and add a reference to the Class Library project (via the Project tab in the Add Reference dialog).
You'll then be able to call the methods in the class library from the other project and you can put breakpoints anywhere to see what's really going on easily.
Ok, so the problem was that any time you edit the class library you have to compile (and the only way I know how is debugging, I can't find a compile button and the publish button doesn't work and building doesn't appear to make a dll). But anyways you have to compile, transfer the file so you are reading the most recent one. If you edit the code during runtime it does NOT update the dll in use...which was my problem.
Using the dojo toolkit, what is the proper way of locally testing code that will be executed as cross-domain, without making the actual build?
As it appears, there are three possible options (each, with their own drawbacks):
Using local (non xd) XMLHttpRequest dojo.require
This option does not really test the xd behavior, since it dojo.require[s] the js synchronously via XHR.
djConfig.debugAtAllCosts = true;
Although this option does load the required code asynchronously (via the 'script' tag), it also pulls the code in via XHR, parses the dojo.require[s] inside that, and pulls them in. This (using the loader_debug), again, is not what the loader_xd is doing. More info on this topic in a different question.
Creating a cross-domain build
This approach requires a build, which is not possible in the environment which I'm running the code in (We're using our own on-the-fly build process, which includes only the js that is necessary for a particular page. This process is not suitable for development).
Thus, my question: is there a way to use the loader_xd, which does not require an xd build (which adds the xd prefix / suffix to every file)?
The 2nd way (using the debugAtAllCosts) also makes me question the motivation for pre-parsing the dojo.require[s]. If the loader_xd will not (or rather can not) pre-parse, why is the method that was created for testing/debugging doing so?
peller has described the situation. If you wanted to just generate .xd.js file for your modules, you could look at util/buildscripts/jslib/buildUtilXd.js and its buildUtilXd.xdgen() function.
It would take a bit of work to make your own script, but you could look at util/buildscripts/build.js for pointers.
I am hoping in the future for Dojo (maybe Dojo 2.x timeframe) we can switch to a loader that just uses script tags with a module format that has a function wrapper around the module, something that is coded by the developer. This would allow the same module format to work in the local and xd cases.
I don't think there's any way to do XD loading without building and deploying it. Your analysis of the various options seems about right.
debugAtAllCosts is there specifically to solve a debugging problem, where most browsers, until recently, could not do anything intelligent with code brought in through eval. Still today, Firefox will report exception in the console as appearing at the eval site (bootstrap.js) with a line number offset from the eval, rather than from the actual eval buffer, and normally that eval buffer is anonymous. Firebug was the first debugger to jump through some hoops to enhance the debugging experience and permitted special metadata that Dojo's loader injects between the XHR and the eval to determine a filepath to the source. Webkit/Safari have recently implemented this also. I believe debugAtAllCosts pre-dates the XD loader.