Using clojurescript 1.10.758 and reagent 1.0.0, I am running into an error in which a file index.js tries to reference $jscomp, which is not defined.
I've seen a number of Stackoverflow and Github issues related to $jscomp being undefined in the context of shadow-cljs, but I'm not using that.
The problem occurs when I use a development mode build with figwheel (using Leiningen with cljsbuild and the figwheel plugin), and also occurs if I use cljsbuild for a once-only development build. Strangely, if I use webpack to create a bundle, the problem does not occur.
Before I tried to make webpack work, I did have working code without webpack. Something I changed seems to have affected the non-bundled build. The only change I can thing of was to install react and react-dom using npm, and exclude those packages from reagent in Leiningen's dependencies. But undoing the exclusion didn't make the non-bundled code work again.
Any suggestions for how to cause $jscomp to be defined when it's first needed?
$jscomp is related to the Closure Compiler and the Polyfills it creates.
It might be enough to tweak the :language-out :es6 compiler options which is somewhat similar to the :output-feature-set option used by shadow-cljs. The best way to debug this is finding the actual code that is getting polyfilled and why. Might require digging through some compiled JS though.
shadow-cljs uses the Closure Compiler more extensively than regular CLJS or figwheel but they also use it. Solutions that apply to shadow-cljs pretty much apply to other tools as well. Just the settings may work a little differently.
Related
I am working on a fully cython compiled python package, using setuptools and some reStructured Text docstrings to generate the pdf documentation using sphinx-autodoc with good success.
The docstrings are not displayed when loading the package in Jupyter Notebooks (using Pylance language server in VSCode). I did not test but suspect that the issue exists in other IDEs or frontends either. Switching to e.g. Jedi as a language server in VSCode did not help.
Using the help(...) command on the routines/classes yields the expected docstring, so the issue does not seem to be with the cython compilation.
There are quite a few issues about formatting issues popping up when searching for Docstrings and Pylance, the issue never seems to be that they simply can not be retrieved.
Since sphinx (autodoc) does not throw any errors and generates a full-package encompassing documentation set fine, this seems a lot like a problem with the language servers to me.
However, I suspect that there may be any compiler directive or setuptools option that I am unaware of that could help - but I do not know about these.
I do have
compiler_directives={'embedsignature': True}
in the setup.py and since the docstrings do show up when using help(..), I do not think this is an issue.
I have also added
import Cython.Compiler.Options
Cython.Compiler.Options.docstrings = True
even though that is indicated as being the default, and it did not change the behavior at all.
Scavenging through the options of Pylance in VSCode was unfruitful, too - I did not expect much there anyways, since obviously the display of the docstrings does work for plenty (all?) other packages that I looked at. Everything is on defaults.
Note: this is not a dupe of this or this other question. Read on: this question is specific to the Code-Sharing template.
I am doing some pretty basic experiments with NativeScript, Angular and the code sharing templates (see: #nativescript/schematics).
Now I am doing some exploration / poc work on how different "build configuration" are supported by the framework. To be clear, I am searching for a simple -and hopefully official- way to have the application use a different version of a specific file (let's call it configuration.ts) based on the current platform (web/ios/android) and environment (development/production/staging?).
Doing the first part is obviously trivial - after all that is the prime purpose of the code sharing schematics. So, different versions of the same file are identified by different extensions. This page explain things pretty simply.
What I don't get as easily is if the framework/template supports any similar convention-based rule that can be used to switch between debug/release (or even better development/staging/production) versions of a file. Think for example of a config.ts file that contains different parameters based on the environment.
I have done some research in the topic, but I was unable to find a conclusive answer:
the old and now retired documentation for the appbuilder platform mentions a (.debug. and .release.) naming convention for files. I don't think this work anymore.
other sources mention passing parameters during the call to tns build / tns run and then fetching them via webpack env variable... See here. This may work, but seems oddly convoluted
third option that gets mentioned is to use hooks to customize the build (or use a plugin that should do the same)
lastly, for some odd reason, the #nativescript/schematics seems to generate a default project that contains two files called environment.ts and environment.prod.ts. I suspect those only work for the web version of the project (read: ng serve) - I wasn't able to get the mobile compiler to recognize files that end with debug.ts, prod.ts or release.ts
While it may be possible that what I am trying to do isn't just supported (yet?), the general confusion an dissenting opinions on the matter make me think I may be missing something.. somewhere.
In case this IS somehow supported, I also wonder how it may integrate with the NativeScript Sidekick app that is often suggested as a tool to ease the build/run process of NativeScript applications (there is no way to specify additional parameters for the tns commands that the Sidekick automates, the only options available are switching between debug/release mode), but this is probably better to be left for another question.
Environment files are not yet supported, passing environment variables from build command could be the viable solution for now.
But of course, you may write your own schematics if you like immediate support for environment files.
I did not look into sharing environment files between web and mobile yet - I do like Manoj's suggestion regarding modifying the schematics, but I'll have to cross that bridge when I get there I guess. I might have an answer to your second question regarding Sidekick. The latest version does support "Webpack" build option which seems to pass the --bundle parameter to tns. The caveat is that this option seems to be more sensitive to typescript errors, even relatively benign ones, so you have to be careful and make sure to fix them all prior to building. In my case I had to lock the version of #types/jasmine in package.json to "2.8.6" in order to avoid some incompatibility between that and the version of typescript that Sidekick's cloud solution is using. Another hint is to check "Clean Build" after npm dependency changes are made. Good luck!
I'm dealing with a very weird issue. For some reason, since a few days, my application doesn't seem to be loading JSON files anymore inside modules.
The app was created with create-react-app, and has been in development for a while without any issues. I've had a dependency in the project (world-countries) that basically only exports a json file. This dependency is not a recent addition.
So, here's the thing. From one day to another, I get the following error while starting/building the app:
Module not found: Error: Cannot resolve module 'json' in /Users/…
As far as I know, I made no changes that would result in this, and create-react-app's webpack version is still the same.
Requiring a random JSON file in the root of my app goes well, somehow this odd behaviour only seems to apply to json files within node_modules in the app.
Some other points:
By this point, I have reinstalled dependencies and node.js multiple times, checked file permissions, etc. To no avail.
Another dependency that also used a json file internally also had this issue, but I managed to circumvent that.
I've explicitly installed json-loader in case something with webpack got messed up, but this didn't make any difference. In fact, I find it curious that _the missing dependency is "json" and not json-loader.
I have a feeling that this is a weird issue caused by some file limit, as when I run the dev server, I get errors relating to too many open files. My project isn't that big, so this seems weird, and I have a feeling it might have something to do with some npm linked modules I have, but there is no recursion or anything.
I'm still quite perplexed, and have no idea what the issue might be. Any suggestions on how to fix this are very welcome
Some people seemed to have had a related issue regarding importing json files in the past. It wasn't in a dependency but I believe it is related.
I took the time to scaffold a new project, import the world-countries modules and log it, and it was working fine.
I would recommend you to update re-scaffold or update all your dependencies, but most notably react-scripts which is version 0.9.5 for me. My create-react-app-version is also 1.3.0.
I have a Unit-Test Project where i used MVVMCross for Dependency Injection, but since i made a Implementation of the Library which i tested for UWP, i kinda wanted to use the Unit-Test for both Implementations.
For that purpose i used Compiler Switches and ended up removing MVVMCross.
But when i uninstall it from the packages i always get "Resource.Attribute" does not contain a definition for "MvxBind" and some other MVVMCross attributes.
I rebuilded the project. I deleted the obj and bin folder and looked through every file in the project folder, but i cant find a thing why it keeps adding those attributes to my Ressource.Designer.cs
If i add MVVMCross back and just dont use it all, obviously it works. But i kinda want to remove it there, since it is just overkill.
Why and how does Polymer use Bower?, and do I NEED to learn to use Bower to use Polymer?
I was going through the Catalog of components, and all of them seem to have a 'Bower Command'.
Thanks for your help.
Edit: Bower is a package manager just as npm, I do understand that much. What I meant to ask is: It can be argued that npm has a wider user base than Bower some even argue that we should stop using bower altogether like here and here. So, how is it beneficial to Polymer the use of bower when there are other options. Is what Polymer does only achievable through bower?
Bower just like npm is a package manager. Here you can see the difference between the two.
No, you don't need to use bower to use Polymer, but without that you'll have to manually download each components that you need, place it at the location from where you can refer it and keep track of newer versions of each package that you have used.
In case you are creating custom elements to publish the situation get even worse as you'll have to pass a file along with your project listing all the dependency and the user will have to manually download each dependency listed in your project and then will have to make sure that he has all the dependencies that were required by your dependencies and so on.
This will make process of custom elements or modules in general very hard to use. That's why such projects use some package management tool.
Edit: since the original question has been edited to ask more about why, the short answer is Bower's focus was for web dependencies, so it results in a flat dependency tree. With Bower now deprecated, the Polymer team's recommendation is to use Yarn with the --flat option. That will also result in a flat dependency structure without multiple versions of the same dependency, which is critical to web development, and something NPM has stated they will never offer.
You should be seeing Components move from Bower to Yarn more, especially after Polymer 3 is released. For more information than you'd ever want about this topic, check out this discussion: https://github.com/package-community/discussions/issues/2