My wish is, that I can build a vue package and install it on any server just by changing the config without recompiling.
My problem:
I don't know how to fetch it.
I use axios for my backend communication at the moment, but I don't know how to download something without knowing the hostname.
I think an ideal solution would be to include a script that contains the config, similar to how the image tag works.
The script should not be minified or included.
But I didn't find a source of anyone doing that (where it worked).
Has anyone a solution for that.
PS: I found this question, but the hostname problem still remains.
Related
We have a script "build": "rollup -c rollup.js --environment production", which when called by some of our team (who use Windows) will on occasion spontaneously not run as normal, but instead just open up the rollup.js config file in an editor. Unfortunately I don't really know where to start with this because I've never been able to replicate it. No logfile is being produced and as far as I've been told ignore-scripts is not set, which are the only other things I've seen related to this behaviour on SO.
Is this a known thing that there's a simple fix for? Or if not, where should I go to find more info about this? Would this be an issue with npm, or with rollup?
I encunter the same sutiation on Windows.
I bypass it by using WSL.
Through some investigating I've tracked this down to what I believe to be a rollup bug with regards to how they're processing their config files. I feel as though I should open a ticket with them regarding this but I've been acting on behalf of a team member and don't have the ability to replicate it on my own, so... I suppose I'll try and coerce them into doing it.
But anyways, so from what I can tell looking at rollup's source, if a rollup config file has a plain .js extension, then it looks as though rollup is running itself on the config to convert it into a CommonJS format, which it will then import and use on the actual build step. Somewhere in this process on Windows something goes awry and the result is that the config file just ends up getting opened with whatever the default handler is for JS files. So basically the solution is to change the file extension.
Our original config was set up using ES6 import/export, and I'm unclear at this point whether changing the extension to .mjs will skip or otherwise change this conversion step, it seems to have worked as such when people have tried it but I can't vouch for it. What I did was to instead go through the config and manually convert all the ES6 import/exports to CommonJS require() and then change the file extension to .cjs (hence our config changed from rollup.js to rollup.cjs) and now it appears to be working consistently across the board.
So here's a question. I'm new to Sylius, and am working on some simple CSS updates. I have a local copy of Sylius running with the built-in webserver: server:run. I also have a development server on Digital Ocean, which runs an (almost) identical copy of Sylius, aside from the configs of course.
Something strange is happening with my CSS update, however. I made a change to .navbar-brand within web/assets/compiled/backend_backend_4.css.
This change showed up immediately on my local. On the development server, however, when pulling down the change (git), and verifying that it now exists in that file, the change doesn't seem to propegate. It's effects aren't shown, inspecting the stylesheet doesn't show them, and furthermore viewing the css file sourcecode directly in the browser does not show the change. But on the filesystem it's definitely there.
I've tried clearing the cache, to no avail.
I also checked the assetic value in both config_dev.yml files, and verified they are both set to use_controller: true
Even still, I tried dumping assetic, to no avail.
So I'm wondering what's going on. Additionally, I realize that I probably shouldn't edit CSS files within a folder called 'compiled'. I'm sure there's a way to do that using a compiler, but I'm not yet familiar with the process and am just making minor changes and learning about caching so far.
Yes you are right you shouldn't be editing the compiled files.
You should edit the source files, then run gulp
or on my system i have to explicitly run npm run gulp
I've documented the solution that worked for me here. It didn't involve Gulp at all, but instead uses Assetic:
Assets need to be installed as hard copies first (I'm not quite sure
what this does exactly, but it seems like an important step because
it copies a lot of assets to places. Documentation was unhelpful but
it was suggested on Stack Overflow somewhere.):
app/console assets:install web
Assets should be edited in web/bundles/[bundle-here]/css or js. This
is frequently within syliusweb if it has to do with page styles /
layouts.
Hint: These assets are referred to in files such as
src/Sylius/Bundle/Resources/views/Backend/layout.html.twig (see the
opening:
(% stylesheets
tag, or search universally for this tag).
Within this tag, you'll see that stylesheets have an output to the compiled folder, but also list the
bundles where they pull their original css from. You should edit one of the source css files, if you'd like your changes to end up in the destination css.
After editing assets, dump assetic:
php app/console assetic:dump
Note - it is also possible to set an assetic watcher on these assets
(google to find out how, think it's a -w flag somewhere), but this is
said to only work in development mode, as it should.
After dumping assetic, the assets from the source bundles compile into their assets/compiled versions, usually combining multiple stylesheets. You should now see your asset refresh!
I created a project using Amber Smalltalk and hosted it on a remote server so multiple people can access it. The network connection is slow and it triggers timeout and just figured that the setting 'waitSeconds' solves the problem.
But, we can't figure out where to set it.The config.js file is generated, and can't be changed manually. Only managed to change it in the default settings in the requirejs source. But that should not be the right place. Please tell me how to solve this problem.
config.js is generated using https://lolg.it/herby/amd-config-builder
from the readme:
The local.amd.json files describe the require.config part for the module at the directory where they are present.
to add WaitSeconds to config.js add it to local.amd.json at the root level of your project.
Can anyone experienced with Webpack/npm components take a loot at: https://github.com/appcomponents/material-components/issues/4 ?
Basically - it is giving error Uncaught Error: Cannot find module "./components" when using this package with npm inside webpack project.
Simple for someone with knowledge but totally blocking for someone totally not into components/webpack.
It's some simple issue with path configuration which is making it impossible to use this really nice package.
I have copied my comment from the GitHub issue as this should have as much visibility as possible.
The issue is with the webpack.config.js. It's not resolving modules correctly.
I've created a pull request (#8) to resolve this issue. You can use that repo commit in the meantime, or you can modify the webpack.config.js file manually in node_modules/vue-material-components/. I've tested this with a known working Vue.js webpack config.
I'm trying to work out how to use DOH to test Dojo modules if I don't install Dojo locally to my project. I'm working in Eclipse and ideally, I'd like something that I can run as part of a Maven build eventually. The Dojo package is 5-20Mb and I don't want to have it stashed in my source control system with each project if possible.
I've tried a few options with the runner.html test runner, but DOH is going to need to find a Dojo somewhere, and then it seems that modules will be found relative to that installation.
Having Dojo installed on my system but not in the project gives me a problem in trying to find the project relative to the location of the dojo.js file. The cross-domain protection prevents me serving up any kind of absolute path as it strips : characters. It also stops me using a Dojo installation served up on a different domain over http.
Is it necessary to have Dojo installed somewhere that I can then define a relative path from dojo.js to the roots of my modules? If not, how do I configure to get around it?
I've not tried this completely cross domain, but yes, you can define paths which may be enough to get you going.
We run our tests using a somewhat complicated deployment (to ensure we don't introduce accidental dojo/doh path dependencies), and our URL looks like this:
http://server/XXX/dev/dohpath/util/doh/runner.html?boot=../../../dojo/dojo.js&dojoUrl=../../../dojo/dojo.js&paths=doh,../dohpath/util/doh;mymodule,../../mymodule&testModule=full.test.module
That is, you fire up the runner, give it both 'boot' and 'dojoUrl' to tell it where Dojo itself lives, use 'paths' to tell DOH where it lives and how to find your own modules.
blech
Whether those relative paths can be made absolute successfuly, and whether it'll work cross-domain is an entirely different matter, I'm afraid. We'll be hitting that problem ourselves in a couple of months.
I've been able to do this with the runner located at http://archive.dojotoolkit.org/nightly/checkout/util/doh/runner.html and a gist.
The trick seems to be to use a path alias in the URL, and use a network-path reference URL (i.e. omit the URL scheme, URL starts with //).
I found this out while trying to answer this question without a local copy of DOH.
Here it is:
http://archive.dojotoolkit.org/nightly/checkout/util/doh/runner.html?testModule=aa&paths=aa,//gist.github.com/gitgrimbo/5406688/raw/e6bc4469ce72dfd6d50e61e885889cb915a3f66b/gistfile1