I have a problem that I have no build error locally and as soon as I deploy with Netlify using Git deploy I get the following error:
[vite]: Rollup failed to resolve import "/dist/css/app.pcss" from "src/main.js".
This is most likely unintended because it can break your application at runtime.
My Folder structure is as-
.
├── README.md
├── dist
│ ├── assets
│ │ ├── favicon
│ │ ├── fonts
│ │ ├── images
│ │ ├── index.e1359b3f.js
│ │ └── index.fb503937.css
│ ├── css
│ │ ├── app.pcss
│ │ └── base
│ │ ├── fonts.pcss
│ │ ├── global.pcss
│ │ ├── headings.pcss
│ │ └── modern-css-reset.pcss
│ └── index.html
├── index.html
├── package-lock.json
├── package.json
├── postcss.config.cjs
├── public
│ ├── assets
│ │ ├── favicon
│ │ ├── fonts
│ │ └── images
│ └── css
│ ├── app.pcss
│ └── base
│ ├── fonts.pcss
│ ├── global.pcss
│ ├── headings.pcss
│ └── modern-css-reset.pcss
├── src
│ ├── App.vue
│ ├── _components
│ ├── _pages
│ ├── main.js
│ └── router
├── tailwind.config.cjs
└── vite.config.js
And I'm importing /dist/css/app.pcss in src/main.js like that:
import '/dist/css/app.pcss'
I will be grateful if you have any ideas:)
The goal is a successful build on netlify via git deploy and thus a successful import of the app.pcss file after the build.
Rather than importing from dist, OP moved his style files towards /src/css and it's now working successfully on Netlify.
Indeed, dist is mainly used as a target for a production app and never as an asset source.
While public, is more for hosting a light resource (like a .pdf) or alike, something that a visitor may need to download at some point on his computer.
I am using redis in telegram bots and now I want to deploy few bots on one cloud server. If it possible to encapsulate data from redis for each project to prevent mistakes?
My directory structure:
/webapps/
├── bot1 <= virtualenv for the application Hello
│ ├── bin
│ │ ├── activate
│ │ ├── gunicorn <= Hello app's gunicorn
│ │ ├── gunicorn_start <= Hello app's gunicorn start script
│ │ └── python
│ ├── hello <= Hello app's bot project directory
│ │ └── hello
│ │ ├── settings.py <= hello.settings
│ │ └── wsgi.py <= hello.wsgi
│ ├── logs <= Hello app's logs will be saved here
│ ├── media
│ ├── run <= Gunicorn's socket file will be placed here
│ └── static
└── bot2 <= analogous virtualenv for the application Goodbye
├── bin
│ ├── activate
│ ├── gunicorn
│ ├── gunicorn_start
│ └── python
├── goodbye
│ └── goodbye
│ ├── settings.py
│ └── wsgi.py
├── logs
├── media
├── run
└── static
I have setting up a configuration in 'wdio.conf.js' for "rpii html reporter". But its not generating master report for all suites.
const { ReportAggregator, HtmlReporter } = require('#rpii/wdio-html-reporter');
exports.config = {
reporters: ['spec', [HtmlReporter, {
debug: true,
outputDir: './reports/html-reports/',
filename: 'report.html',
reportTitle: 'Test Report Title',
showInBrowser:true
}
]],
onPrepare: function (config, capabilities) {
let reportAggregator = new ReportAggregator({
outputDir: './reports/html-reports/',
filename: 'master-report.html',
reportTitle: 'Master Report'
});
reportAggregator.clean() ;
global.reportAggregator = reportAggregator;
},
onComplete: function(exitCode, config, capabilities, results) {
(async () => {
await global.reportAggregator.createReport( {
config: config,
capabilities: capabilities,
results : results
});
})();
}
}
I expect single report with multiple test cases. But I'm getting multiple reports for each test cases.
The topic is pretty old atm, but I just addressed a similar issue in my project - cannot generate the report at all. In most of the case, it is just a matter of configuration, but there is no solid document or guideline for this painful wdio reporter configuration. So here I am, after a whole week of research and testing around, these are viable config you will need and other fellows out there who is/was facing the same issue.
First, let assume your project structure would be something like the below tree
.
├── some_folder1
│ ├── some_sub_folder1
│ ├── some_sub_folder2
├── some_folder2
├── #report
│ ├── html-reports
│ ├── template
│ │ ├── sanity-mobile-report-template.hbs
│ │ ├── wdio-html-template.hbs
├── specs
│ ├── test1
│ │ ├── test1.doSuccess.spec.js
│ │ ├── test1.doFail.spec.js
│ ├── test2
│ │ ├── test2.doSuccess.spec.js
│ │ ├── test2.doFail.spec.js
├── node-modules
├── package.json
Second, you should have templates for your reports, in my case, it is located in #report/template wdio-html-template.hbs and sanity-mobile-report-template.hbs for HtmlReporter and ReportAggregator respectively. As Rich Peters has notices above
Each suite is executed individually and an html and json file are
generated. wdio does not aggregate the suites, so this is done by the
report aggregator collecting all the files and creating an aggregate
file when complete
The HtmlReporter will actually need to find it template for generating the content for each .spec file, then there is a need for another template requested by ReportAggregator
Third, you need correct specs and suites declaration in your wdio config, generic for specs, and file specifically for suites.
Final, run your test using --suite parameter, reference to wdio guideline
My final project structure would look like this, notice the changes
.
├── some_folder1
│ ├── some_sub_folder1
│ ├── some_sub_folder2
├── some_folder2
├── #report
│ ├── html-reports
│ ├── ├── screenshots
│ ├── ├── suite-0-0
│ ├── ├── ├── 0-0
│ ├── ├── ├── ├── report.html
│ ├── ├── ├── ├── report.json
│ ├── ├── ├── 0-1
│ ├── ├── ├── ├── report.html
│ ├── ├── ├── ├── report.json
│ ├── ├── master-report.html
│ ├── ├── master-report.json
│ ├── template
│ │ ├── sanity-mobile-report-template.hbs
│ │ ├── wdio-html-template.hbs
├── specs
│ ├── test1
│ │ ├── test1.doSuccess.spec.js
│ │ ├── test1.doFail.spec.js
│ ├── test2
│ │ ├── test2.doSuccess.spec.js
│ │ ├── test2.doFail.spec.js
├── node-modules
├── package.json
Each suite is executed individually and an html and json file are generated. wdio does not aggregate the suites, so this is done by the report aggregator collecting all the files and creating an aggregate file when complete.
I've been working with Silex a few times now. And I like it, but sometimes, the documentation confuses me simply because they use another folder structure.
Who can tell me which folder structure they use exactly in Silex 2.0?
Documentation
├── composer.json
├── composer.lock
├── vendor
│ └── ...
└── web
└── index.php
Where are the views, controllers etcetera stored?
Silex is not a "convention over configuration" framework: it does not prescribe nor care what the structure of your file system or application organisation is; that is why there's no mention of such things in the docs.
Just organise things the way that best suits your own needs.
Just for example, a directory structure I usually use.
├── config
│ └── dev.php
│ └── test.php
│ └── ...
├── src PSR-4 compatible directory structure
│ └── Component Customized components (Symfony's components or any other)
│ └── Security
│ └── ...
│ └── Validator
│ └── ...
│ └── ...
│ └── Controller
│ └── DataFixtures
│ └── Migrations
│ └── Provider My service providers
│ └── Serivice My services
│ └── Auth
│ └── ...
│ └── Registration
│ └── ...
│ └── ...
│ └── Application.php Customized Silex application class
├── tests
├── var
│ └── cache
│ └── log
│ └── ...
├── vendor
│ └── ...
├── web
│ └── index.php
│ └── index-test.php
├── composer.json
├── composer.lock
And my implementation on GitHub. It's currently WIP, but you can use it as a boilerplate for your Silex application.
I need an advice about the architecture and code organize of my app. I developed React Native application. Our business requires two apps instead one. The current app - for the current target audience. The second app should be for other target audience. Each app should have web-version. Part of the code in the application will be the same (business logic, features, common screens). The other part will be different. The app will have the different design theme, texts, icons, auth methods, payment methods and some more features.
I see it so:
├── mobile
│ ├── app1
│ │ ├── .env
│ │ ├── index.android.js (symlink to ../../lib/mobile/app/index.android.js)
│ │ ├── index.ios.js (symlink to ../../lib/mobile/app/index.ios.js)
│ │ ├── ios (symlink to ../../lib/mobile/app/ios)
│ │ ├── android (symlink to ../../lib/mobile/app/android)
│ │ ├── src
│ │ ├── node_modules
│ │ └── package.json
│ └── app2
│ ├── .env
│ ├── index.android.js (symlink to ../../lib/mobile/app/index.android.js)
│ ├── index.ios.js (symlink to ../../lib/mobile/app/index.ios.js)
│ ├── ios (symlink to ../../lib/mobile/app/ios)
│ ├── android (symlink to ../../lib/mobile/app/android)
│ ├── src
│ ├── node_modules
│ └── package.json
├── web
│ ├── app1
│ │ ├── src
│ │ ├── .env
│ │ ├── app.js
│ │ └── package.json
│ └── app2
│ ├── src
│ ├── .env
│ ├── app.js
│ └── package.json
└── lib
├── mobile
│ ├── app
│ │ ├── index.android.js
│ │ ├── index.ios.js
│ │ ├── ios
│ │ ├── android
│ │ ├── src (shared js-code for all mobile apps)
│ │ └── package.json
├── web
│ └── app
│ └── src (shared js-code for all mobile apps)
└── src (shared and business-logic js-modules for all apps)
Who had a similar experience? I will be glad to hear any ideas or advice from you.