When I disable translation language fallback, then key translations are displayed instead of a particular translation.
However, when running with SSR mode, translation keys are not displayed at all.
I am using the latest version of Spartacus and running server by npm run build:ssr && npm run serve:ssr.
Is there any way to have missing translations displayed in prod mode with enabled SSR?
TLDR;
It's a correct behavior. If you need a custom fallback behavior, please overwrite this method:
https://github.com/SAP/spartacus/blob/4432a2bed0c6cf04aa2ff412792f0e8cb24686a3/projects/core/src/i18n/i18next/i18next-translation.service.ts#L70
Explanation:
SSR runs the production version of the application.
In development mode missing keys are rendered in the HTML (and a warning appears in the console). But in production mode missing keys are rendered in the HTML as a non-breaking space is displayed.
See https://sap.github.io/spartacus-docs/i18n/#fallback-language
Related
I am attempting to get the volar vue language server to work in place of vetur for neovim's native lsp.
Using both lspconfig and lspinstall I was able to create a working custom install for sumneko_lua (unrelated but had to manually build due to some issues with the built-in :LspInstall lua). Below is that code duplicated and modified for an attempt at using this new vue server:
local vue_config = require'lspinstall/util'.extract_config('vuels')
vue_config.default_config.cmd = {'node', './node_modules/vscode-vue-languageservice/out/index.js', '--stdio'}
require'lspinstall/servers'.newvue = vim.tbl_extend('error', vue_config, {
install_script = [[
! test -f package.json && npm init -y --scope=lspinstall || true
npm install vscode-vue-languageservice#latest
]],
uninstall_script = nil
})
Running :LspInstall newvue installs properly, however :LspInfo shows this language server is attached to the buffer (of a .vue file) but not active. I believe the issue is with this path: ./node_modules/vscode-vue-languageservice/out/index.js. It exists, but may not be the correct entry point? The default vue ls simply has vls as the command because it provides a binary. Am I missing something in this package? I have yet to come across another language server without a single binary to pick out.
Thanks!
Can you try an absolute path to the out.js file? In my pretty elaborate config for a custom Volar install I'm using something just /home/myuser/dev/volar/packages/server/out/index.js (where the volar folder is just the whole volar cloned github repo). My full config is here
I don't think you can use relative paths like you did. I know you're assuming that the "./node_modules" means "workspace directory" but it's hard to tell in which directory nvim-lspconfig opens up those executables.
I have yet to come across another language server without a single binary to pick out.
Volar also provides a binary, it's volar-server (after running npm i -g #volar/server), it's just with a custom install (ie. alongside the real volar) you can't use it, because I assume you want to use your local install with custom code.
As for more indepth debugging/logging, you can check ~/.cache/nvim/lsp.log to see why the language server dies in detail.
This is a quick question:
I'm performing an ng serve
--env=dev100 --aot (the dev100 is our remote server)
The element:
<app-layout></app-layout> **<--- LOOKS LIKE THIS upon completion. EMPTY!**
But, I don't get this issue with I simply do ng serve on my local box.
I've never seen this happen and there are no errors.
Thoughts?
Due to the wonkiness of angular 5's compiler, I had a dead component (something I wasn't using) and had the same signature, per se, as the one that was not being loaded.
EX:
<app-layout></app-layout> <-- NOT BEING LOADED
<app-layout-popover></app-layout-popover> <-- NOT BEING USED
My thought is that the compiler saw only the first part
After I removed the dead component, it compiled and everything's working.
I built an Electron app and I am now looking at how to distribute it.
I went with electron-builder to handle packaging etc.
For a bit of context, as a web developer, I am used to continuously deploy web apps on a web server but I have a hard time figuring out how to distribute a packaged one in Electron.
In electron-builder docs there is a brief mention about testing auto-update:
"Note that in order to develop/test UI/UX of updating without packaging the application you need to have a file named dev-app-update.yml in the root of your project, which matches your publish setting from electron-builder config (but in YAML format)"
But, it's rather vague...
So I actually have two questions:
1. How do I actually test the auto-update flow?
Do I need to actually publish a new version to trigger an update locally? Seems pretty unclear, it would be like developing against the production server.
2. Is it possible to have a fallback for unsigned code?
I don't have yet any certificate for code signing. So the OS/app will block the auto-update. But, I'd still want to tell the user that an update is available so they can go and download the app manually. Can I do that? (going back to point 1, I'd like to be able to test this flow)
I've just finished dealing with this. I also wanted to test against a non-production server and avoid having to package my app each time I iterated. To test downloads I had to sign my app, which slowed things down. But it sounds like you just need to check for updates. Which I think you can do as follows...
I created a dummy github repo, then created a a file dev-app-update.yml containing:
owner: <user or organization name>
repo: dev-auto-update-testing
provider: github
The path where this file is expected to be defaults to a place you can't access. Thankfully, you can override it like so:
if (isDev) {
// Useful for some dev/debugging tasks, but download can
// not be validated becuase dev app is not signed
autoUpdater.updateConfigPath = path.join(__dirname, 'dev-app-update.yml');
}
...that should be enough for your case -- since you don't need downloads.
If not, here are some other tips:
you can change the repo setting in your electron-builder config to point at your dummy repo then package your app. This will give you a packed, production build that points at your dummy repo -- this is how I did my download testing (though I have a cert, and signed my app)
you should be calling autoUpdate's checkForUpdates(), but if checkForUpdatesAndNotify() gives you a useful OS Notification then you should be able to set autoUpdater.autoDownload to false and end up with what you need.
Lastly, it sounds you could skip autoUpdater, since you won't be using the download feature anyway. Instead you could use github's releases api, assuming you use github to host your release. If not then your host should have something similar. Use that to check for updates then tell the user from within your App (could present them with a clickable URL too). If you want OS Notifications electron has a module for that.
We're using electron-updater with GitHub as a provider for auto-updates. Unfortunately, it breaks a lot and the electron-builder team doesn't support these issues well (1, 2, 3) (from my own experience, but you can find more examples on GitHub).
One way to test updates in dev mode:
Create a build of your app with an arbitrarily high version number
Create a public repo and publish the above build
Create a dev-app-update.yml next to your main entry point and configure it for the repo above (see)
In your main entry point:
import { autoUpdater } from "electron-updater";
...
if (process.env.NODE_ENV === "development") {
// Customize the test by toggling these lines
// autoUpdater.autoDownload = false
// autoUpdater.autoInstallOnAppQuit = false;
autoUpdater.checkForUpdates();
}
Then when running yarn dev you should see something like:
Checking for update
...
Found version 100.0.0 (url: <>.exe)
Downloading update from <>.exe
updaterCacheDirName is not specified in app-update.yml Was app build using at least electron-builder 20.34.0?
updater cache dir: C:\Users\<>\AppData\Local\Electron
New version 100.0.0 has been downloaded to C:\Users\<>\AppData\Local\Electron\pending\<>.exe
And it should install when you close the dev app.
This should give you some certainty but we still ran into issues in production. If you want to be sure, play through the full update flow with a test repo but packaged production apps just as you would do with the live one.
There is a javascript library, pre-built and available on npm, that I wish to develop with/debug. In my case, it is openlayers.
In the classic way of requiring a javascript file and wanting to debug, one would just switch the script url from the production version to the debug version, ie:
to
However, when using webpack and then importing via npm:
import openlayers from 'openlayers'
Gets you the production distribution of the library, the same as the ol.js script from above.
On a side note, to stop webpack trying to parse a prebuilt library and throw a warning about that you must include something like this:
// Squash OL whinging
webpackConfig.module.noParse = [
/\/dist\/ol.*\.js/, // openlayers is pre-built
]
Back to the problem at hand: how can I conditionally load a different entry-point for a module prebuilt and imported like this?
Of course, I can do it in a hacky way. By going into the node_modules/openlayers/package.json and switching the browser field from
"browser": "dist/ol.js",
to
"browser": "dist/ol-debug.js",
Is there a way I can request a different entry point via webpack or by using a different import syntax? Do I first have to petition the library maintainers to update the browser field to allow different entry point hints to browsers, according to the spec? https://github.com/defunctzombie/package-browser-field-spec
Thoughts on a more effective way to make this happen? Yearning to be able to programmatically switch loading of the production and debug versions of a library based on env variables.
Webpack has configuration options for replacing a module into a different path: https://webpack.github.io/docs/configuration.html#resolve-alias
This resolves the openlayers import to use the debug version:
webpackConfig.resolve.alias: {
openlayers: 'openlayers/dist/ol-debug.js'
}
In my build system I have a function that takes the environment type and returns the matching webpackConfig. Based on the parameter I include the above snippet or not.
Full code: webpack-multi-config.js
I have two different (gulp-) tasks for development and production. For example the production task: webpackProduction.js
Line 1 imports the config script with production as type.
My build system is based on gulp starter.
I am implementing the bundling and minification support in MVC4 and it appears as though it is making my javascript files bigger than if they weren't bundled/minified. I am using the latest build available in nuget (pre-release option on). I have the following bundle set up in my RegisterBundles class.
bundles.Add(new ScriptBundle("~/bundles/baseJS").Include(
"~/Scripts/jquery-1.7.1.js",
"~/Scripts/jquery.cookie.js",
"~/Scripts/jquery-ui-1.8.11.js",
"~/Scripts/bootstrap.js",
"~/Scripts/jquery.pjax.js",
"~/Scripts/kendo/2012.1.515/js/kendo.all.min.js",
"~/Scripts/jquery.jstree.js",
"~/Scripts/jquery.unobtrusive-ajax.js",
"~/Scripts/jquery.validate.js",
"~/Scripts/jquery.validate.unobtrusive.js",
"~/RIS.Scripts/PostJson.js"));
And I am loading it into my _Layout.cshtml using
#Scripts.Render("~/bundles/baseJS")
When I add up the bytes received in Fiddler for these scripts in debug mode I get the following
Name Size(bytes)
jquery 98013
jquery cookie 1455
jquery ui 124704
bootstrap 52378
pjax 8138
kendo.all 219751
jstree 55045
unobtrusive-ajax 2492
validate 13323
validate-unobtrusive 5138
postjson 634
Total 581071
And when I run it on my production server I get the following from fiddler for the entire js bundle.
Bytes Received: 999,396
What is going on here? Most of the files are minified to some extent, but it shouldn't almost double the size of my payload.
Additional details-
When I download the js files off my local dev box (fiddler reported size 379kb) and the server (fiddler reported size 999kb) and put them in kdiff they are binary identical. When I look in Chrome's developer tools network tab, the local server downloads 379kb, but the 'Parser' value is 975kb. What is this parser value. Could it be that there is some IIS compression setting that is not set in my server but is on my local IIS server? The only difference I note is the fact that the IIS Express I am running on my dev machine is 8.0 where the server is IIS 7.5.
Most likely what you are seeing here is some of the debug/release 'magic' that comes from the FileExtensionReplacementList.
Let's take jQuery for example. Typically in your scripts folder you will see two copies of each file, i.e. jquery-1.6.2.js and jquery-1.6.2.min.js.
By default optimization will use the min.js version when debug=false, and use the regular jquery-1.6.2.js when debug=true, since typically that makes debugging easier (no bundling and no minification of the bundle).
This file selection 'magic' is controlled via the FileExtensionReplacementList on BundleCollection.
In the next release (RTM), there will be a bit more granularity in this list, as typically developers will want to target when these are should be used, i.e.
list.Add("min", OptimizationMode.WhenEnabled);
list.Add("debug", OptimizationMode.WhenDisabled);
You have the bundling option working, but the minification is done by an BundleTable.EnableOptimizations = true setting and some "transform" options that you've haven't engaged. See CssMinify and JsMinify.
Something along the lines of:
var b1 =new ScriptBundle("~/bundles/jquery").Include(
"~/Scripts/jquery-1.*");
b1.Transforms.Add(new JsMinify());
bundles.Add(b1);
- and -
BundleTable.EnableOptimizations = true;