I'm using nightwatch.js, selenoid and chrome driver. I want browser to go to any url, that is not local e.g. browser.url('http://google.com'). But chrome driver doesn't proceed this request, however if I use https, everything works fine. I've tried to add flag, but it didn't work for me.
desiredCapabilities: {
networkConnectionEnabled: true,
browserName: 'chrome',
version: 'latest',
...
acceptSslCerts: false,
acceptInsecureCerts: true,
args: ['--disable-web-security', '--allow-running-insecure-content', '--allow-external-pages', '--allow-http-background-page'],
'goog:chromeOptions': {
args: ['--disable-web-security', '--allow-running-insecure-content', '--allow-external-pages', '--allow-http-background-page'],
},
chrome: {
args: ['--disable-web-security', '--allow-running-insecure-content', '--allow-external-pages', '--allow-http-background-page'],
},
},
I am not sure why you have to pass all these args. I have the below config.
https://github.com/spnraju/nightwatchjs-selenium-example/blob/master/nightwatch.conf.js
I am loading google and Mercury using http which works for me.
https://github.com/spnraju/nightwatchjs-selenium-example/blob/master/tests/mercury.js
https://github.com/spnraju/nightwatchjs-selenium-example/blob/master/tests/google.js
Hope this helps.
Related
Here's my svelte.config.js and I'm using adapter-static :
const config = {
kit: {
adapter: adapter({
// default options are shown
pages: '../backend/build',
assets: '../backend/build',
fallback: null,
precompress: false,
}),
alias: {},
appDir: '_app',
browser: {
hydrate: true,
router: true,
},
files: {
assets: 'static',
hooks: 'src/hooks',
lib: 'src/lib',
params: 'src/params',
routes: 'src/routes',
serviceWorker: 'src/service-worker',
template: 'src/app.html',
},
floc: false,
methodOverride: {
parameter: '_method',
allowed: [],
},
paths: {
assets: '',
base: '',
},
trailingSlash: 'always',
vite: {
server: {
proxy: {
'/api': 'http://localhost:5555',
},
},
},
},
preprocess: null,};
From the backend (Go lang) I'm serving build directory & index.html file. The homepage works fine but whenever I click on any route, it sends get request to the server instead of redirecting in the app itself.
Here's the go code to serve from backend:
router := gin.Default()
router.StaticFile("/", "./build/index.html")
router.StaticFS("/_app", http.Dir("build/_app"))
I have also tried with the following code:
router.NoRoute(func(c *gin.Context) {
path := c.Request.URL.Path
c.File("./build/index.html")
})
Note: Things work fine when I run npm run preview.
The adapter-static has two distinct modes of operation: SPA and prerendering. When there are several routes, both the npm run dev and npm run preview works as intended, but once built, the static routing falls to the web server, in your case, the Go framework, but the same happens with any other static server (I have tested also Nginx and Apache).
I found a workaround to avoid converting the site to a SPA: Installing a url rewrite mechanism as a middleware in order to add the .html extension that the static server is expecting in the compiled site. In my case, I used Go Fiber github.com/gofiber/rewrite/v2 and it worked as intended (the same behavior as when using npm run dev)
For Nginx static server the solution is the same url rewrite and it could be used as explained here: https://www.codesmite.com/article/clean-url-rewrites-using-nginx
The homepage works fine but whenever I click on any route, it sends get request to the server instead of redirecting in the app itself
SvelteKit users internal router, or $app/navigator for links only if it detects a link to be the same domain as the current page. Likely your web server is misconfigured and there is a mismatch of domain somewhere in
The web browser address bar
Web server configuration
However, the question do not contain these details and is thus unanswerable "why" and how to fix it.
I just want to make VS Code's debugger work with webpack-dev-server without ignoring my breakpoints.
Now, webpack-dev-server serves the bundled files from memory, while, if I understand this correctly, the VS Code debugger searches for them on disk (...or not?...)
As a result, whenever I set a breakpoint I get the dreaded
Breakpoint ignored because generated code not found (source map problem?)
Now, every related question I could find had to do with typescript mostly, and not with the fact that webpack-dev-server serves from memory. I am not using typescript. Seems that people are either not using webpack-dev-server, or I am missing something blatantly obvious, with my money on the latter.
This is my VS Code launch.json
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"type": "chrome",
"request": "launch",
"name": "Launch Chrome against localhost",
"url": "http://localhost:8080",
"webRoot": "${workspaceRoot}",
"sourceMaps": true,
"trace": true
}
]
}
and these are the related lines from my webpack.config.js
devtool: 'cheap-module-source-map',
output: {
path: path.join(__dirname, 'dist'),
filename: '[name].[chunkhash].js'
},
I have tried various modifications to the launch.json to no avail, so I am just pasting it in vanilla form.
Note that the output.path is only used when there is a production build and the files are spewed to disk.
Here is what the structure of the files is in the served page:
And here is the command I am running in development
"scripts": {
"start": "webpack-dev-server --host 0.0.0.0 --config ./webpack.config.js"
},
Finally, here is a relevant chunk from the trace file
From target: {"method":"Debugger.scriptParsed","params":{"scriptId":"30","url":"http://localhost:8080/manifest.0ec68ebd5f0abf9b4cd4.js","startLine":0,"startColumn":0,"endLine":150,"endColumn":57,"executionContextId":2,"hash":"216099518F33D6091EC12795265804FB35669A30","executionContextAuxData":{"isDefault":true,"frameId":"18228.1"},"isLiveEdit":false,"sourceMapURL":"manifest.0ec68ebd5f0abf9b4cd4.js.map","hasSourceURL":false,"isModule":false,"length":5906}}
Paths.scriptParsed: could not resolve http://localhost:8080/manifest.0ec68ebd5f0abf9b4cd4.js to a file under webRoot: e:\Mitch\Workspace\Projects\project-name. It may be external or served directly from the server's memory (and that's OK).
SourceMaps.getMapForGeneratedPath: Finding SourceMap for http://localhost:8080/manifest.0ec68ebd5f0abf9b4cd4.js by URI: manifest.0ec68ebd5f0abf9b4cd4.js.map and webRoot: e:\Mitch\Workspace\Projects\project-name
SourceMaps.loadSourceMapContents: Downloading sourcemap file from http://localhost:8080/manifest.0ec68ebd5f0abf9b4cd4.js.map
To client: {"seq":0,"type":"event","event":"script","body":{"reason":"new","script":{"id":1,"source":{"name":"manifest.0ec68ebd5f0abf9b4cd4.js","path":"http://localhost:8080/manifest.0ec68ebd5f0abf9b4cd4.js","sourceReference":1001}}}}
To client: {"seq":0,"type":"event","event":"scriptLoaded","body":{"path":"http://localhost:8080/manifest.0ec68ebd5f0abf9b4cd4.js"}}
SourceMap: creating for http://localhost:8080/manifest.0ec68ebd5f0abf9b4cd4.js
SourceMap: sourceRoot:
SourceMap: sources: ["webpack:///webpack/bootstrap 7617f9bf7c8b0bc95159"]
SourceMap: webRoot: e:\Mitch\Workspace\Projects\project-name
SourceMap: no sourceRoot specified, using webRoot + script path dirname: e:\Mitch\Workspace\Projects\project-name\
SourceMap: mapping webpack:///webpack/bootstrap 7617f9bf7c8b0bc95159 => webpack\bootstrap 7617f9bf7c8b0bc95159, via sourceMapPathOverrides entry - "webpack:///*": "*"
SourceMaps.scriptParsed: http://localhost:8080/manifest.0ec68ebd5f0abf9b4cd4.js was just loaded and has mapped sources: ["webpack\\bootstrap 7617f9bf7c8b0bc95159"]
From my experience (about 15 mins ago), if 'webpack.config.js' has a value for the context property, then that has to be accounted for for '.vscode/launch.json'.
For an example, if 'webpack.config.js' has the following:
module.exports = {
context: path.resolve(__dirname, 'src'),
entry: './index.ts',
Then launch.json needs that context ('src') too:
"url": "http://localhost:8080/",
"webRoot": "${workspaceRoot}/src",
"sourceMaps": true,
I just updated/fixed my repo so now TypeScript breakpoints should bind.
https://github.com/marckassay/VSCodeNewProject
For Webpack 4:
Install webpack-cli locally if you don't already have it installed (it has been pulled out of webpack).
Add the following VSCode debug configuration to your .vscode/launch.json (that's the file that VSCode opens when you click on the wheel icon in Debug view):
{
"type": "node",
"request": "launch",
"name": "build",
"program": "${workspaceFolder}/node_modules/.bin/webpack-cli",
"args": [
"--config",
"webpack.config.prod.js"
],
"autoAttachChildProcesses": true,
"stopOnEntry": true
}
stopOnEntry will make debugger stop in the very first (shebang) line of webpack.js, like this:
Old thread, but it still comes up in searches...
It feels like turning on "writing the generated code to disk" might be the solution here:
As per https://webpack.js.org/configuration/dev-server/#devserverwritetodisk-, add this to webpack.config.js:
module.exports = {
//...
devServer: {
writeToDisk: true
}
};
If in case someone troubling with start-server-webpack-plugin of webpack:
I have recently stuck on the same issue and #MarkoBonaci's answer came to rescue. However, I stuck on another error which is produced by the webpack plugin: start-server-webpack-plugin.
Below is the error I got, when I launched by application via debugger of vscode:
cd /home/me/projects/villager-topics ; env "NODE_ENV=development"
/home/me/.nvm/versions/node/v11.6.0/bin/node --inspect-brk=33538
node_modules/.bin/webpack-cli --colors --progress --config
./webpack.dev.js Debugger listening on
ws://127.0.0.1:33538/d8bb6d64-a1a1-466e-9501-6313a3dc8bcf For help,
see: https://nodejs.org/en/docs/inspector Debugger attached.
clean-webpack-plugin: /home/rajeev/projects/villager-topics/dist has
been removed. 10% building 1/1 modules 0 active webpack is watching
the files…
98% after emitting StartServerPluginStarting inspector on
127.0.0.1:33538 failed: address already in use
As you can see StartServerPlugin is using the same port 33538 which is already taken by the parent process. So we need to tell StartServerPlugin to use some other port for its inspection initialization. This, we can achieve through the initialization of StartServerPlugin.
new StartServerPlugin({
name: 'server.js',
nodeArgs: ['--inspect=5858'], // allow debugging),
})
Here in nodeArgs we are specifying the inspect port as 5858. After this configuration is saved and then relaunch the application through Debugger of vscode, you will successfully start the application.
So some quick background on the site's current setup:
My company's site currently runs off of a CMS. All pages are generated and routed via the CMS, so there are no .html files anywhere. It's all generated via razor (.cshtml), the CMS as a backend/data-store, and routing is handled through the CMS.
If it were up to me I'd rewrite the entire thing, but I don't have that luxury. I'm doing my best to rewrite the site with a Vue.js + webpack front-end wherever possible and slowly rebuild this site over time using more modern techniques than are currently implemented.
However, I'm running into a problem setting up Webpack's dev server with our current configuration.
I think I know what the problem is, however I'm having difficulty understanding the http-proxy-middleware's configuration settings.
I believe the way I currently have everything setup, the dev server is proxying everything - therefore not picking up any changes I make to the .vue/.js files I modify (via hot reloading).
Unfortunately I HAVE to proxy the majority of the site (pages [.cshtml files], legacy scripts, various APIs, etc.), however I don't want to proxy MY .js files and .vue files (you can assume anything of mine is in /dist/ or /src/. Everything else is the old site and must be proxied via "my.server".
Additionally, I set this up as a quick test via vue cli's webpack-simple configuation - however I can also set it up via the non-simple variation if needed. I started with "-simple" to "K.I.S.S" (Keep it simple stupid) and slowly layer on the complexity as desired.
Here's my webpack.config.js file as it currently stands:
var path = require('path')
var webpack = require('webpack')
module.exports = {
entry: './src/main.js',
output: {
path: path.resolve(__dirname, './dist'),
publicPath: '/dist/',
filename: 'build.js'
},
module: {
rules: [
{
test: /\.vue$/,
loader: 'vue-loader',
options: {
loaders: {
// Since sass-loader (weirdly) has SCSS as its default parse mode, we map
// the "scss" and "sass" values for the lang attribute to the right configs here.
// other preprocessors should work out of the box, no loader config like this nessessary.
'scss': 'vue-style-loader!css-loader!sass-loader',
'sass': 'vue-style-loader!css-loader!sass-loader?indentedSyntax'
}
// other vue-loader options go here
}
},
{
test: /\.js$/,
loader: 'babel-loader',
exclude: /node_modules/
},
{
test: /\.(png|jpg|gif|svg)$/,
loader: 'file-loader',
options: {
name: '[name].[ext]?[hash]'
}
}
]
},
resolve: {
alias: {
'vue$': 'vue/dist/vue.common.js'
}
},
devServer: {
historyApiFallback: true,
noInfo: true,
proxy: {
'/': {
target: {
"host": "my.server",
"protocol": 'http:',
"port": 80
},
ignorePath: false,
changeOrigin: true,
secure: false
}
}
},
performance: {
hints: false
},
devtool: '#eval-source-map'
}
if (process.env.NODE_ENV === 'production') {
module.exports.devtool = '#source-map'
// http://vue-loader.vuejs.org/en/workflow/production.html
module.exports.plugins = (module.exports.plugins || []).concat([
new webpack.DefinePlugin({
'process.env': {
NODE_ENV: '"production"'
}
}),
new webpack.optimize.UglifyJsPlugin({
sourceMap: true,
compress: {
warnings: false
}
}),
new webpack.LoaderOptionsPlugin({
minimize: true
})
])
}
As far as I can tell the issue lies in the proxy:
proxy: {
'/': {
target: {
"host": "my.server",
"protocol": 'http:',
"port": 80
},
ignorePath: false,
changeOrigin: true,
secure: false
}
}
Obviously the '/' is targeting everything, but while I can find plenty of examples of how to proxy specific sections and not anything else, I need the opposite. I need to proxy everything EXCEPT /dist/ and /src/. Any help would be greatly appreciated - and who knows, I may be way off here and this isn't even my problem.
Ultimately, though, the issue is when I run the dev server, if I setup proxying, everything on the site runs except my .vue files - if I don't proxy the server, nothing runs except my .vue files. Therefore it stands to reason the proxying simply needs to be applied to the legacy portions only and not the vue portions - but if I'm way off base, that's the ultimate issue and I'm open to solutions of any kind.
Thanks in advance for any insight anyone can provide!
webpack-dev-server allows you to configure multiple proxy configurations.
Using this style of configuring the proxy will give access to more advanced context filtering via the context option.
You can use globbing:
proxy: [{
context: ['**', '!/src/**', '!/dist/**', '!**/*.vue'],
target: {
"host": "my.server",
"protocol": 'http:',
"port": 80
},
ignorePath: false,
changeOrigin: true,
secure: false
}]
Or you can write your own filtering logic.
proxy: [{
context: function(pathname, req) {
// exclude /src/ and /dist/
return !pathname.match("^/(src|dist)/");
},
target: {
"host": "my.server",
"protocol": 'http:',
"port": 80
},
ignorePath: false,
changeOrigin: true,
secure: false
}]
sources:
https://github.com/chimurai/http-proxy-middleware#context-matching
https://github.com/webpack/webpack-dev-server/issues/562#issuecomment-241736936
https://github.com/webpack/webpack-dev-server/blob/ee9181ca3ae40d35f8e419123423df51f2f40700/examples/proxy-hot-reload/webpack.config.js#L4
I'm using ydn-db to build a test app that can work offline in mutliple borwsers and devices.
My first option was to use indexedDB but then I realised that not all browsers and devices support it.
So, after some research I decided to move to ydn-db.
I'm initializing the db by doing this:
var dbSchema = {
version: DB_VERSION,
//autoSchema: true,
stores: [{
name: DB_STORE_USERS_NAME,
autoIncrement: false, // optional.
indexes: [{
name: 'login', // optional
keyPath: 'login',
unique: true,
multiEntry: false
}]
}, {
name: DB_STORE_REPOS_NAME,
autoIncrement: false, // optional.
indexes: [{
name: 'userid', // optional
keyPath: 'owner.id',
unique: false
}]
}]
};
db = new ydn.db.Storage(DB_NAME, dbSchema);
This works fine in chrome, but when I test it in ie9 I get the following error:
SCRIPT5007: Unable to get value of the property 'XMLDocument': object is null or undefined.
Do you have any clue of what can be the issue here?
I'm using the last version of ydn-db as it is in the site http://dev.yathit.com/ydn-db/downloads.html.
I'm downloading the following modules:
IndexedDb, WebSql, Webstorage, Userdata, Query
XMLDocument, which is available only in older IE (with compatibility mode in IE9 ?) is used to persist data with UserData storage mechanism on DOM node. See more detail on UserData and XMLDocument.
IE9 should use WebStorage (localStorage) instead. Also try out with IE6 or IE7. You will get better picture.
So somewhere mechanisms detection is screwed up. If you have more detail info, I could help out.
If I have a store, like this example:
var myStore = Ext.create("Ext.data.Store", {
model: "User",
proxy: {
type: "ajax",
url : "/users.json",
reader: {
type: "json",
rootProperty: "users"
}
},
autoLoad: true
});
I want to cache the users.json file in the application cache, so I add it to app.json as follows:
/**
* Used to automatically generate cache.manifest (HTML 5 application cache manifest) file when you build
*/
"appCache": {
/**
* List of items in the CACHE MANIFEST section
*/
"cache": [
"index.html",
"users.json"
],
/**
* List of items in the NETWORK section
*/
"network": [
"*"
],
/**
* List of items in the FALLBACK section
*/
"fallback": []
},
Looking in Chrome developer tools, I can see that the .json file has been added to the application cache correctly, along with index.html.
I would expect this to 'just work' offline. Unfortunately it doesn't, it tries to request the json file, which doesn't work as it is offline, and then it no longer uses that data in the application.
The rest of the application works perfectly fine. Any ideas?
Found the solution from looking into the API documentation and doing a bit of trial and error with properties. It is not obvious at all.
The problem was, the requests for the .json files was being appending with additional arguments, ?dc=XXXXXXX and paging arguments. There are two additional properties that need to be applied to the proxy: noCache and enablePagingParams. This did the trick.
var myStore = Ext.create("Ext.data.Store", {
model: "User",
proxy: {
type: "ajax",
url : "/users.json",
noCache: false,
enablePagingParams: false,
reader: {
type: "json",
rootProperty: "users"
}
},
autoLoad: true
});
I also needed to update the header comment on my test cache.manifest file, to ensure that the changes to the stores were detected correctly, as I kept getting Loader errors. This isn't a problem once you use sencha CMD to build the production version as it auto-generates the application cache file for you.
NOTE: I did already have the following, widely documented, in my app.js file as well:
Ext.Loader.setConfig({
disableCaching: false
});
Hope this helps someone!