Ionic 3: Page module mapping not compiling correctly

Short description of the problem:
Using the latest Ionic 3 beta, an error occurs when loading the root page. It seems to be caused by how app-scripts creates the page module mapping, so I'm posting it here.
What behavior are you expecting?
It should load. My page modules are just like the lazy-load branch of the conference-app and I'm using the @IonicPage() decorator on my pages.
Let me know if you need more debug info!
Steps to reproduce:

Use <ion-nav root="AccountLoginPage"></ion-nav>
The ids.slice(1).map(...) below errors as ids.length === 1 for all pages

var map = {
	"../pages/account-activate/account-activate.module": [
		99
	],

	(...)

	"../pages/tour/tour.module": [
		127
	]
};
function webpackAsyncContext(req) {
	var ids = map[req];	if(!ids)
		return Promise.reject(new Error("Cannot find module '" + req + "'."));
	return Promise.all(ids.slice(1).map(__webpack_require__.e)).then(function() {
		return __webpack_require__(ids[0]);
	});
};
webpackAsyncContext.keys = function webpackAsyncContextKeys() {
	return Object.keys(map);
};
module.exports = webpackAsyncContext;
webpackAsyncContext.id = 95;

//////////////////
// WEBPACK FOOTER
// ./src async
// module id = 95
// module chunks = 0

Which @ionic/app-scripts version are you using?
1.2.2
Other information:
ERROR TypeError: undefined is not a function
    at Array.map (native)
    at webpackAsyncContext (http://localhost:8100/build/main.js:56228:34)
    at loadAndCompile (http://localhost:8100/build/main.js:93852:35)
    at NgModuleLoader.load (http://localhost:8100/build/main.js:93817:83)
    at ModuleLoader.load (http://localhost:8100/build/main.js:69245:44)
    at DeepLinker.getNavLinkComponent (http://localhost:8100/build/main.js:38001:39)
    at DeepLinker.getComponentFromName (http://localhost:8100/build/main.js:37984:25)
    at getComponent (http://localhost:8100/build/main.js:45278:23)
    at convertToView (http://localhost:8100/build/main.js:45296:16)
    at Nav.setRoot (http://localhost:8100/build/main.js:54640:103)
    at SafeSubscriber._next (http://localhost:8100/build/main.js:125073:43)
    at SafeSubscriber.__tryOrSetError (http://localhost:8100/build/main.js:30319:16)
    at SafeSubscriber.next (http://localhost:8100/build/main.js:30261:27)
    at Subscriber._next (http://localhost:8100/build/main.js:30201:26)
    at Subscriber.next (http://localhost:8100/build/main.js:30165:18)

Cordova CLI: 6.5.0
Ionic Framework Version: 3.0.0-beta.3
Ionic CLI Version: 2.2.1
Ionic App Lib Version: 2.2.0
Ionic App Scripts Version: 1.2.2
ios-deploy version: 1.9.1
ios-sim version: 5.0.13
OS: macOS Sierra
Node Version: v6.9.1
Xcode version: Xcode 8.2.1 Build version 8C1002

@Manduro,
Can you give me access to the repo so I can see what's going on? I can add some unit tests to account for whatever case we're missing.
Thanks,
Dan

Here is my deeplinkconfig log as requested here.

{
    "links": [
        {
            "loadChildren": "../pages/account-activate/account-activate.module#AccountActivatePageModule",
            "name": "AccountActivatePage",
            "segment": "activeren/:email/:token",
            "priority": "low",
            "defaultHistory": []
        },
        {
            "loadChildren": "../pages/account-forgot/account-forgot.module#AccountForgotPageModule",
            "name": "AccountForgotPage",
            "segment": "wachtwoord-aanvragen",
            "priority": "low",
            "defaultHistory": [
                "HomePage",
                "AccountLoginPage"
            ]
        },
        {
            "loadChildren": "../pages/account-invite/account-invite.module#AccountInvitePageModule",
            "name": "AccountInvitePage",
            "segment": "account-aanmaken/:email/:token/:networkId",
            "priority": "low",
            "defaultHistory": [
                "HomePage"
            ]
        },
        {
            "loadChildren": "../pages/account-login/account-login.module#AccountLoginPageModule",
            "name": "AccountLoginPage",
            "segment": "inloggen",
            "priority": "low",
            "defaultHistory": [
                "HomePage"
            ]
        },
        {
            "loadChildren": "../pages/account-reset/account-reset.module#AccountResetPageModule",
            "name": "AccountResetPage",
            "segment": "reset-wachtwoord/:email/:token",
            "priority": "low",
            "defaultHistory": []
        },
        {
            "loadChildren": "../pages/account-signup/account-signup.module#AccountSignupPageModule",
            "name": "AccountSignupPage",
            "segment": "account-aanmaken",
            "priority": "low",
            "defaultHistory": [
                "HomePage",
                "AccountLoginPage"
            ]
        },
        {
            "loadChildren": "../pages/account-terms/account-terms.module#AccountTermsPageModule",
            "name": "AccountTermsPage",
            "segment": null,
            "priority": "low",
            "defaultHistory": []
        },
        {
            "loadChildren": "../pages/account-unsubscribe/account-unsubscribe.module#AccountUnsubscribePageModule",
            "name": "AccountUnsubscribePage",
            "segment": "afmelden/:token",
            "priority": "low",
            "defaultHistory": []
        },
        {
            "loadChildren": "../pages/advertorial-form/advertorial-form.module#AdvertorialFormPageModule",
            "name": "AdvertorialFormPage",
            "segment": null,
            "priority": "low",
            "defaultHistory": []
        },
        {
            "loadChildren": "../pages/advertorial/advertorial.module#AdvertorialPageModule",
            "name": "AdvertorialPage",
            "segment": null,
            "priority": "low",
            "defaultHistory": []
        },
        {
            "loadChildren": "../pages/calendar-attendance/calendar-attendance.module#CalendarAttendancePageModule",
            "name": "CalendarAttendancePage",
            "segment": null,
            "priority": "low",
            "defaultHistory": []
        },
        {
            "loadChildren": "../pages/calendar-create/calendar-create.module#CalendarCreatePageModule",
            "name": "CalendarCreatePage",
            "segment": null,
            "priority": "low",
            "defaultHistory": []
        },
        {
            "loadChildren": "../pages/calendar-detail/calendar-detail.module#CalendarDetailPageModule",
            "name": "CalendarDetailPage",
            "segment": null,
            "priority": "low",
            "defaultHistory": []
        },
        {
            "loadChildren": "../pages/calendar-export/calendar-export.module#CalendarExportPageModule",
            "name": "CalendarExportPage",
            "segment": null,
            "priority": "low",
            "defaultHistory": []
        },
        {
            "loadChildren": "../pages/calendar-recurring/calendar-recurring.module#CalendarRecurringPageModule",
            "name": "CalendarRecurringPage",
            "segment": null,
            "priority": "low",
            "defaultHistory": []
        },
        {
            "loadChildren": "../pages/calendar/calendar.module#CalendarPageModule",
            "name": "CalendarPage",
            "segment": null,
            "priority": "low",
            "defaultHistory": []
        },
        {
            "loadChildren": "../pages/group-invite/group-invite.module#GroupInvitePageModule",
            "name": "GroupInvitePage",
            "segment": null,
            "priority": "low",
            "defaultHistory": []
        },
        {
            "loadChildren": "../pages/group-user/group-user.module#GroupUserPageModule",
            "name": "GroupUserPage",
            "segment": null,
            "priority": "low",
            "defaultHistory": []
        },
        {
            "loadChildren": "../pages/group/group.module#GroupPageModule",
            "name": "GroupPage",
            "segment": null,
            "priority": "low",
            "defaultHistory": []
        },
        {
            "loadChildren": "../pages/home/home.module#HomePageModule",
            "name": "HomePage",
            "segment": "home",
            "priority": "low",
            "defaultHistory": []
        },
        {
            "loadChildren": "../pages/network-create/network-create.module#NetworkCreatePageModule",
            "name": "NetworkCreatePage",
            "segment": null,
            "priority": "low",
            "defaultHistory": []
        },
        {
            "loadChildren": "../pages/network/network.module#NetworkPageModule",
            "name": "NetworkPage",
            "segment": "netwerk/:networkId",
            "priority": "low",
            "defaultHistory": []
        },
        {
            "loadChildren": "../pages/settings-notifications/settings-notifications.module#SettingsNotificationsPageModule",
            "name": "SettingsNotificationsPage",
            "segment": null,
            "priority": "low",
            "defaultHistory": []
        },
        {
            "loadChildren": "../pages/settings-user/settings-user.module#SettingsUserPageModule",
            "name": "SettingsUserPage",
            "segment": null,
            "priority": "low",
            "defaultHistory": []
        },
        {
            "loadChildren": "../pages/topic-create/topic-create.module#TopicCreatePageModule",
            "name": "TopicCreatePage",
            "segment": null,
            "priority": "low",
            "defaultHistory": []
        },
        {
            "loadChildren": "../pages/topic-detail/topic-detail-popover.module#TopicDetailPopoverModule",
            "name": "TopicDetailPopover",
            "segment": null,
            "priority": "low",
            "defaultHistory": []
        },
        {
            "loadChildren": "../pages/topic-detail/topic-detail.module#TopicDetailPageModule",
            "name": "TopicDetailPage",
            "segment": null,
            "priority": "low",
            "defaultHistory": []
        },
        {
            "loadChildren": "../pages/topics/topics.module#TopicsPageModule",
            "name": "TopicsPage",
            "segment": null,
            "priority": "low",
            "defaultHistory": []
        },
        {
            "loadChildren": "../pages/tour/tour.module#TourPageModule",
            "name": "TourPage",
            "segment": null,
            "priority": "low",
            "defaultHistory": []
        }
    ]
}

@danbucholtz I'll set up a stripped private copy of my repo and give you access.

@danbucholtz Here is a minimal repo that reproduces the issue: https://github.com/Manduro/ionic-test

I have a theory that this is being caused by the automated @IonicPage generator failing to create an entryComponents stanza.

Same issue here. After updating to the latest ionic 3, routing no more works because of
ERROR
TypeError: Array.prototype.map callback must be a function
map
webpackAsyncContext — src async:114
loadAndCompile — ng-module-loader.js:54
load — module-loader.js:32
getNavLinkComponent — deep-linker.js:168
getComponent — nav-util.js:14
push — nav-controller-base.js:81
previewTimesheet — month-review.ts:469
(anonymous function)
callWithDebugContext — core.es5.js:13060
(anonymous function) — platform-browser.es5.js:2674
onInvokeTask — core.es5.js:4136
runTask — polyfills.js:3:10401
invoke — polyfills.js:3:16178

PS. I have observed that my project generates single main.js file, while the conference app have multiple split chunks of main.js, maybe that's something to do with it as well.

The problem with this approach is that it seems my providers are no longer singletons.

My problem boiled down to the moment.js library.   When it's being used then code splitting breaks you start getting the dreaded undefined is not a function error.

FWIW I am also using moment.js.

@brettatoms Great, great catch, thanks for sharing!
@danbucholtz
I've updated my test repo to reproduce it correctly this time. https://github.com/Manduro/ionic-test

See angular-cli #2496 for more info.

Ditching moment in favor of date-fns seems to have fixed me.

For now you can work around this by adding node_modules/moment/moment.js to the includes in your tsconfig.json file and replace any moment imports in your code with declare var moment;

@rapropos,
What a weird issue with Moment. Any thoughts on it? I am going to take a look. It seems strange to me since we're letting Webpack do the heavy lifting there.
Hmmm.
Thanks,
Dan

@danbucholtz: The most comprehensive resource I have come across to date, which I suspect is also where @brettatoms found this (major props to you on this, BTW) is angular-cli #2496 as mentioned above. I cannot independently confirm that all wildcard imports silently break code splitting or not, but at least in my case, any occurrence of import * as moment from "moment" did. As I also said upthread:

I also note that the conference app has a bunch of [n].main.js files in www/build that appear to be code splitting artifacts, whereas my app does not have any of these.

...and corroborated by @Sh1d0w  with:

I have observed that my project generates single main.js file, while the conference app have multiple split chunks of main.js, maybe that's something to do with it as well.

...so it seems pretty conclusive that whatever the root cause, failure to see webpack code splitting act as expected is a proximate cause for this issue.

I can confirm that "undefined is not a function" runtime error related to module loading.
Made a simple app based on the sidemenu template (using ng4/ionic3 and lazy loading). The app fails right on first load as soon as I have installed angular2-moment and specified MomentModule in the imports section of app.module.ts
Remove it from there and everything is back to normal.
Looking forward to advice on proper solution / fix and best practices moving forward.

Thanks for this, having same issue, tried many different things, no real progress.

@rapropos I wish I had found the problem in that angular-cli issue but unfortunately is was through a LOT of trial and error.
The problem doesn't happen with all wildcard imports since we're also doing import _ from lodash with no problems.

Looks like I'm having the same issue with chart.js.

This is the corresponding PR that has fixes the angular-cli issue that was mentioned. Maybe that's something to work with?
https://github.com/angular/angular-cli/pull/4153

Yep, we're aware of the PR. Currently looking into it and seeing if this will help for us.

It's interesting that the ng-cli PR seems to be AoT-specific. I was bit by this issue even without using ngc, just on a straight dev build.

This is fixed. Please test and let me know how it goes.
npm install @ionic/app-scripts@latest --save --save-exact

@danbucholtz Thanks! I can confirm it is fixed now for my project.

@danbucholtz Working great.  chart.js is also fixed but I suspect the problem there is it was also importing moment. Thanks!!!

@danbucholtz There's still some breakage with import 'moment-timezone'.  It doesn't seem to be able to modify the moment object and add the .tz methods.
[08:15:00]  ionic-app-script task: "build"
[08:15:00]  Error: Failed to transpile TypeScript
Error: Failed to transpile TypeScript
    at errorCheckProgram (/Users/brett/devel/nextglass/untappd-app/node_modules/@ionic/app-scripts/dist/aot/aot-compiler.js:114:39)
    at /Users/brett/devel/nextglass/untappd-app/node_modules/@ionic/app-scripts/dist/aot/aot-compiler.js:52:29

     L143:        this.checkinData.timezone = moment().tz(moment.tz.guess()).format('z');

            Property 'tz' does not exist on type 'typeof moment'.

     L143:        this.checkinData.timezone = moment().tz(moment.tz.guess()).format('z');

@danbucholtz Works ok with import moment from 'moment-timezone';

FWIW, I couldn't find the exact change that fixed it, but I noticed that it didn't work with<EMAIL_ADDRESS>, but worked with<EMAIL_ADDRESS>

Still having this issue on 1.3.7, If I have my rootPage set as a string. It just breaks and throws undefined is not a function

@realappie, me too - any advances on this?

@jamesbenns I gave up using the pages as modules and just used them the traditional way.

@realappie I think that's the best way at the moment. Making global pipes is clumsy too - it seems there's not a good way. Page modules are for another day.

@jamesbenns I agree with you. And because I consider ionic to be a super cutting edge framework,  Im sure ionic page modules will work better in the future.

I'm having the same issue. I have an ionic app that works fine. I use the ionic cli to generate a new page, I then import the page module in app.module, without adding any code to the page, and I get the error.
Uncaught (in promise): TypeError: Array.prototype.map callback must be a function
Environment setup:
Ionic Framework: 3.2.0
Ionic App Scripts: 1.3.7
Angular Core: 4.1.0
Angular Compiler CLI: 4.1.0
Node: 7.7.1
OS Platform: macOS Sierra
Navigator Platform: MacIntel
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/603.1.30 (KHTML, like Gecko) Version/10.1 Safari/603.1.30

Exactly the same issue here. I'm going back to chucking the pages in app.module for now.
Error:
Runtime Error
Uncaught (in promise): TypeError: undefined is not a function TypeError: undefined is not a function at Array.map (native) at webpackAsyncContext (http://localhost:8100/build/main.js:74105:34) at loadAndCompile (http://localhost:8100/build/main.js:73181:36) at NgModuleLoader.load (http://localhost:8100/build/main.js:73146:83) at ModuleLoader.load (http://localhost:8100/build/main.js:55211:44) at DeepLinker.getNavLinkComponent (http://localhost:8100/build/main.js:26281:39) at DeepLinker.getComponentFromName (http://localhost:8100/build/main.js:26264:25) at getComponent (http://localhost:8100/build/main.js:29339:23) at convertToView (http://localhost:8100/build/main.js:29357:16) at convertToViews (http://localhost:8100/build/main.js:29376:32)

ionic info:
global packages:

    @ionic/cli-utils : 1.1.2
    Ionic CLI        : 3.1.2

local packages:

    @ionic/app-scripts              : 1.3.7
    @ionic/cli-plugin-ionic-angular : 1.1.2
    Ionic Framework                 : ionic-angular 3.2.1

Got same issue, my ionic env is:
Your system information:

    Cordova CLI: 6.5.0
    Ionic Framework Version: 3.3.0
    Ionic CLI Version: 3.0.0-beta.4
    ios-deploy version: 1.7.0
    ios-sim version: 4.1.1
    OS: macOS Sierra
    Node Version: v7.7.3
    Xcode version: Xcode 8.1 Build version 8B62

Same problem here when navigating using a string instead of a reference to a page component.
I'm not using any third party librarys, just pure ionic 3.
 Runtime Error
Uncaught (in promise): TypeError: undefined is not a function TypeError: undefined is not a function
at Array.map (native)
at webpackAsyncContext (http://localhost:8100/build/main.js:74778:34)
at loadAndCompile (http://localhost:8100/build/main.js:73758:36)
at NgModuleLoader.load (http://localhost:8100/build/main.js:73723:83)
at ModuleLoader.load (http://localhost:8100/build/main.js:55474:44)
at DeepLinker.getNavLinkComponent (http://localhost:8100/build/main.js:26907:39)
at DeepLinker.getComponentFromName (http://localhost:8100/build/main.js:26890:25)
at getComponent (http://localhost:8100/build/main.js:29965:23)
at convertToView (http://localhost:8100/build/main.js:29983:16)
at convertToViews (http://localhost:8100/build/main.js:30002:32)

Error: Uncaught (in promise): TypeError: undefined is not a function TypeError: undefined is not a function     at Array.map (native)     at webpackAsyncContext (http://localhost:8100/build/main.js:74778:34)     at loadAndCompile (http://localhost:8100/build/main.js:73758:36)     at NgModuleLoader.load (http://localhost:8100/build/main.js:73723:83)     at ModuleLoader.load (http://localhost:8100/build/main.js:55474:44)     at DeepLinker.getNavLinkComponent (http://localhost:8100/build/main.js:26907:39)     at DeepLinker.getComponentFromName (http://localhost:8100/build/main.js:26890:25)     at getComponent (http://localhost:8100/build/main.js:29965:23)     at convertToView (http://localhost:8100/build/main.js:29983:16)     at convertToViews (http://localhost:8100/build/main.js:30002:32)     at c (http://localhost:8100/build/polyfills.js:3:13190)     at Object.reject (http://localhost:8100/build/polyfills.js:3:12546)     at NavControllerBase._fireError (http://localhost:8100/build/main.js:43667:16)     at NavControllerBase._failed (http://localhost:8100/build/main.js:43655:14)     at http://localhost:8100/build/main.js:43710:59     at t.invoke (http://localhost:8100/build/polyfills.js:3:8971)     at Object.onInvoke (http://localhost:8100/build/main.js:4406:37)     at t.invoke (http://localhost:8100/build/polyfills.js:3:8911)     at r.run (http://localhost:8100/build/polyfills.js:3:4140)     at http://localhost:8100/build/polyfills.js:3:13731
`global packages:
@ionic/cli-utils : 1.3.0
Ionic CLI        : 3.3.0

local packages:
@ionic/app-scripts              : 1.3.7
@ionic/cli-plugin-ionic-angular : 1.3.0
Ionic Framework                 : ionic-angular 3.3.0`

Seems broken again with just creating new ionic 3 project and generating 2 new pages. Noe extra libs installed. @danbucholtz

Happens for me as well.  Have an existing app where pages work just fine the old way, but now converting them to use @IonicPage decorator and modules.
However i get two different errors depending how i load the problem page.  If i enter using the /#/notifications url route, i get this error
AppComponent.html:1 ERROR TypeError: undefined is not a function     at Array.map (native)     at webpackAsyncContext (http://localhost:8100/build/main.js:162535:34)     at loadAndCompile (http://localhost:8100/build/main.js:143320:36)     at NgModuleLoader.load (http://localhost:8100/build/main.js:143285:83)     at ModuleLoader.load (http://localhost:8100/build/main.js:111473:44)     at DeepLinker.getNavLinkComponent (http://localhost:8100/build/main.js:74663:39)     at DeepLinker.initViews (http://localhost:8100/build/main.js:74837:21)     at Nav.ngAfterViewInit (http://localhost:8100/build/main.js:105123:33)     at callProviderLifecycles (http://localhost:8100/build/main.js:11418:18)
If i try to nav into the page using the ionicpage decorator, as a string, that is
nav.push('notifications')
i get a different Error
core.es5.js:1084 ERROR Error: Uncaught (in promise): TypeError: undefined is not a function TypeError: undefined is not a function     at Array.map (native)     at webpackAsyncContext (http://localhost:8100/build/main.js:162535:34)     at loadAndCompile (http://localhost:8100/build/main.js:143320:36)     at NgModuleLoader.load (http://localhost:8100/build/main.js:143285:83)     at ModuleLoader.load (http://localhost:8100/build/main.js:111473:44)     at DeepLinker.getNavLinkComponent (http://localhost:8100/build/main.js:74663:39)     at DeepLinker.getComponentFromName (http://localhost:8100/build/main.js:74646:25)     at getComponent (http://localhost:8100/build/main.js:79998:23)     at convertToView (http://localhost:8100/build/main.js:80016:16)     at convertToViews (http://localhost:8100/build/main.js:80035:32) ...
Page decorators
@IonicPage({   name: 'notifications' }) @Component({   selector: 'notifications',   templateUrl: 'notifications.html', }) export class NotificationsPage implements OnInit { ...
Module for my page
`import { NgModule } from '@angular/core';
import { IonicPageModule } from 'ionic-angular';
import { SharedModule } from '../../app/shared.module';
import { NotificationsPage } from './notifications';
// http://masteringionic.com/blog/2017-04-14-lazy-loading-and-deep-linking-with-ionic-3/
// https://github.com/ionic-team/ionic-app-scripts/issues/848
@NgModule({
declarations: [
NotificationsPage
],
imports: [
IonicPageModule.forChild(NotificationsPage),
SharedModule
],
entryComponents: [],
providers: [],
exports: [NotificationsPage],
})
export class NotificationsModule { }`

Re: my previous comment: I got this working without updating or changing any packages.  Not sure how exactly just trying different things.  I have a shared module with a huge ton of services and pages, so one change I made was moving the BrowserModule out of shared and having it directly in app.module.   Also I added  entryComponents: [NotificationsPage], on the page module.
Anyway I hope this info helps somebody.

We are having the same issue here, looks like not solved yet.
I'm creating the page using ionic g page MyPage.
If I try to call the page using this.nav.setRoot('MyPage'), it fails. But if I use this.nav.setRoot(MyPage) // the reference to the component, not a string, it works.

@danbucholtz The things are broken here, could you reopen the issue?

Please provide a minimal example project to inspect.

@mhartington
I've just provided the steps to reproduce on main git (not sure if this is a app-scripts problem)
https://github.com/ionic-team/ionic/issues/12136

@mhartington
Tried to create a plunker to reproduce, but looks like IonicPage don't work over plunker, the error is "Invalid link: First Page".
http://plnkr.co/edit/Puzkvf
But reproducing the bug using ionic serve is very fast.

Put together a demo and push to github then.

I'm encountering the same issue using ionic 3.4.0.
I've posted a sample app demonstrating the bug @ https://github.com/kael/ionic-deeplinking-bug-demo
I've also tried by adding imports: [NavigationPageModule] in app.module.ts as mentioned in that SO response (but not mentioned in the @IonicPage doc) but unsuccessfully.
Seems I have to fallback to the former navigation mechanism.

@kael your project was not setup correctly. Lazy-loaded pages should not be declared in the app-module, as you had.
Please see my blog posts that go into detail about lazy loading.
http://blog.ionic.io/ionic-and-lazy-loading-pt-1/
http://blog.ionic.io/ionic-and-lazy-loading-pt-2/
https://github.com/kael/ionic-deeplinking-bug-demo/pull/1

@mhartington: thank you very much for the fix.
There's still an issue as mentioned on the PR page, when appending directly the path to the host in the address bar (but for my use that won't be a problem).
Cheers.

Interesting. If you load the localhost:8100, then manually apply the #/navigation slug, it errors. If you open a new tab, and load locahost:8100/#/navigation it loads fine.
I installed nightly and it seems to be fixed. Though the urls have changed a bit.

URLs are in phase one of two as we build out a PWA story. They are going to change a bit in 3.5.0 which ships tomorrow and likely going to shrink down again in the next release after that.
Thanks,
Dan

Guys we really appreciate your effort and the great stuff you are doing with Ionic. However don't you feel that Ionic is a big framework, used by a lot of projects nowadays and promoting something broken in official release is not a good practice? I mean you always rush to announce cool stuff which then don't work for like 5 releases until it gets properly fixed and ready to use in production?
My point is: if you are going constantly to change and rewrite the framework, add new things or deprecate old ones, the please do it as a dev or beta release, don't do regular releases which then appears to be broken. General public should always use what is stable.
 Then the developer has to decide if he wants to upgrade to get those nice fixes or wait 4-5 releases to get the new stuff fixed. It will be much nice if you just release a dev or beta previews so users can test them if they want, but officially release and include this feature when it is bullet proof. Otherwise you are only causing problems with production builds.
I am focusing here Lazy loading and virtual scroll, but it could apply for anything new you want to introduce in future.
@danbucholtz @mhartington

By all means, feel free not to upgrade or wait until the next release. We fixed a ton of navigation bugs, but as a result we had to change the url a bit. We feel that it's better to ship the fixes now than to wait. We will likely be able to shrink the url down some in the near future, and then set-it-and-forget it. There are very few people who are using the url today so it isn't a big deal compared to the many, many, many devs using Ionic via Cordova.
Thanks,
Dan

@danbucholtz Please pay attention to my last sentence in my previous post. It was not related directly to your last comment regarding URLs it was more towards releasing unstable stuff in prod.
You can't tell developers "feel free to not upgrade", when this release provides a fixes for previously released unstable stuff for example.
Once again I don't mean to argue, I really appreciate all work you are doing, I just think your release lifecycle is very wrong.
For example I do lectures where I present Ionic to another developers. When someone decides to give it a try and he for example wants to test Lazy loading feature and he sees it is broken, what impressions are you leaving in him?
What Ionic should provide is a rock solid solution, instead of always changing an unreliable releases.
@danbucholtz @mlynch

As a side note if there is still a confusion what I am talking about it is not even about upgrading from one release to another.
Same applies for newcomers that just create their first Ionic project. See my comment here https://github.com/ionic-team/ionic-app-scripts/issues/848#issuecomment-307612380
With just a blank starter app, used ionic-cli to generate two new pages without installing anything else, and just following the blog post about lazy loading it just not works.
This is what I am talking about.

@Sh1d0w Is it still broken for you? Because it works fine for me on a project I created today
This is my ionic info output.
global packages:

    @ionic/cli-utils : 1.0.0-rc.2-alpha.f5850eb3
    Cordova CLI      : 6.5.0
    Ionic CLI        : 3.0.0-rc.2-alpha.f5850eb3

local packages:

    @ionic/app-scripts              : 1.3.12
    @ionic/cli-plugin-cordova       : 1.4.0-alpha.e838a5d7
    @ionic/cli-plugin-ionic-angular : 1.3.1-alpha.e838a5d7
    Cordova Platforms               : none
    Ionic Framework                 : ionic-angular 3.5.0

System:

    Node       : v6.9.5
    OS         : macOS Sierra
    Xcode      : Xcode 8.3.3 Build version 8E3004b
    ios-deploy : not installed
    ios-sim    : not installed

I have the same problem, repo at https://github.com/basvdijk/ionic-module-test when you open the sidebar and click the test entry I'll get:
Runtime Error
Uncaught (in promise): TypeError: undefined is not a function TypeError: undefined is not a function at Array.map (<anonymous>) at webpackAsyncContext (http://localhost:8100/build/main.js:74580:34) at loadAndCompile (http://localhost:8100/build/main.js:73742:36) at NgModuleLoader.load (http://localhost:8100/build/main.js:73707:83) at ModuleLoader.load (http://localhost:8100/build/main.js:56081:44) at DeepLinker.getNavLinkComponent (http://localhost:8100/build/main.js:26699:39) at DeepLinker.getComponentFromName (http://localhost:8100/build/main.js:26682:25) at getComponent (http://localhost:8100/build/main.js:29762:23) at convertToView (http://localhost:8100/build/main.js:29782:16) at convertToViews (http://localhost:8100/build/main.js:29801:32)

Error: Uncaught (in promise): TypeError: undefined is not a function
TypeError: undefined is not a function
    at Array.map (<anonymous>)
    at webpackAsyncContext (http://localhost:8100/build/main.js:74580:34)
    at loadAndCompile (http://localhost:8100/build/main.js:73742:36)
    at NgModuleLoader.load (http://localhost:8100/build/main.js:73707:83)
    at ModuleLoader.load (http://localhost:8100/build/main.js:56081:44)
    at DeepLinker.getNavLinkComponent (http://localhost:8100/build/main.js:26699:39)
    at DeepLinker.getComponentFromName (http://localhost:8100/build/main.js:26682:25)
    at getComponent (http://localhost:8100/build/main.js:29762:23)
    at convertToView (http://localhost:8100/build/main.js:29782:16)
    at convertToViews (http://localhost:8100/build/main.js:29801:32)
    at c (http://localhost:8100/build/polyfills.js:3:13190)
    at Object.reject (http://localhost:8100/build/polyfills.js:3:12546)
    at NavControllerBase._fireError (http://localhost:8100/build/main.js:44151:16)
    at NavControllerBase._failed (http://localhost:8100/build/main.js:44139:14)
    at http://localhost:8100/build/main.js:44194:59
    at t.invoke (http://localhost:8100/build/polyfills.js:3:8971)
    at Object.onInvoke (http://localhost:8100/build/main.js:4427:37)
    at t.invoke (http://localhost:8100/build/polyfills.js:3:8911)
    at r.run (http://localhost:8100/build/polyfills.js:3:4140)
    at http://localhost:8100/build/polyfills.js:3:13731

global packages:

    @ionic/cli-utils : 1.4.0
    Ionic CLI        : 3.4.0

local packages:

    @ionic/app-scripts              : 1.3.12
    @ionic/cli-plugin-ionic-angular : 1.3.1
    Ionic Framework                 : ionic-angular 3.5.0

System:

    Node       : v7.2.0
    OS         : OS X El Capitan
    Xcode      : Xcode 8.2.1 Build version 8C1002
    ios-deploy : not installed
    ios-sim    : 5.0.13
    npm        : 4.0.5

@basvdijk your demo repo does not actually include any lazy loading at all. Not sure if you pushed the wrong code up or something. The way to repo currently is setup, you would never have that issue.

@mhartington Sorry seems I forgotten to push my changes. Please pull for a version with the test module.

Similar to another example posted here, your setup is not correct.
@@ -6,7 +6,6 @@ import { MyApp } from './app.component';
 import { HomePage } from '../pages/home/home';
 import { ListPage } from '../pages/list/list';

-import { TestModule } from '../test/test.module';

 import { StatusBar } from '@ionic-native/status-bar';
 import { SplashScreen } from '@ionic-native/splash-screen';
@@ -18,7 +17,6 @@ import { SplashScreen } from '@ionic-native/splash-screen';
     ListPage
   ],
   imports: [
-    TestModule,
     BrowserModule,
     IonicModule.forRoot(MyApp),
   ],

You don't import the module for the lazy loaded page at all.

@mhartington I see, thanks for clarifying!


Expensive requests in form steps

I use this bundle to create a wizard and it works well. I fill the forms using data I get by doing a request to an external application. These requests may take a significant amount of time (up to 10 seconds). I request this data in the buildForm function.
Unfortunately when using the same construction as in the example controller, the buildForm function is called multiple times. E.g. if I am on step 3 and I want to navigate to step 4 it is called 4 times (once with flow_step = 1, once with flow_step = 2, etc). Since most steps do this slow request to the external application it can take up to 40 seconds to navigate to page 4.
Is there a way to prevent doing these expensive requests for each already completed step? Or is the only way to request all this data before starting the wizard?

Take a look at https://github.com/craue/CraueFormFlowBundle/blob/master/README.md#disabling-revalidation-of-previous-steps.

Sorry I forgot to mention that I already tried setting that to false, but it does not seem to work. buildForm is still called multiple times.

Oh right, that's something different. There's no quick solution then.

Ah okay, thank you :+1:

Its a pitty there is no solution
I've been using for a while now but the calls of buildforms all the forms (8 steps) is too expensive making the wizard too slow


Why numeric folder generate automatically ?

Please check the following instructions before submitting a bug :

Make sure you are using the latest version.
Make sure you read installation, integration, and upgrade document.

And provide the followings :

Operating system : Ubuntu 18.04
Laravel version : 7.24
Package version :2.1
Steps to reproduce your issue :
Screenshots of browser console :

Why automatically generating numeric "1" folder inside photos folder.

Because your user ID is 1
disable this setting if you want in config/lfm.php allow_private_folder

Because your user ID is 1
disable this setting if you want in config/lfm.php allow_private_folder

Thanks.


Can't find ID on execution_db

Hi There
I'm trying to test a basic stackstorm serverless configuration, but I keep on running into the following issue:
Traceback (most recent call last):
  File "/var/task/~st2/deps/lib/python2.7/site-packages/eventlet/hubs/poll.py", line 114, in wait
    listener.cb(fileno)
  File "/var/task/~st2/deps/lib/python2.7/site-packages/eventlet/greenthread.py", line 218, in main
    result = function(*args, **kwargs)
  File "/var/task/~st2/deps/lib/python2.7/site-packages/st2common/runners/utils.py", line 176, in read_and_store_stream
    store_data_func(execution_db=execution_db, action_db=action_db, data=line)
  File "/var/task/~st2/deps/lib/python2.7/site-packages/st2common/services/action.py", line 387, in store_execution_output_data
    execution_id = str(execution_db.id)
AttributeError: 'NoneType' object has no attribute 'id'

This appears to be a bug, can you advise?

Thanks for reporting this.
We will have a look as soon as we get a chance - it's likely related to some recent code change in StackStorm/st2 repo.

Hiya
I think this may be as a result of the "actionrunner.stream_output" which defaulted to True as of Stackstorm 2.6.0 (Jan 2018). It wasn't clear to me reading through the docs where you set global StackStorm options - can you advise?

I believe you are correct.
You need to set it in st2.conf. This means this file in this repo - https://github.com/StackStorm/serverless-plugin-stackstorm/blob/master/stackstorm/st2.conf.

I merged #33 into master.
Can you please try to install latest plugin version using npm from git master and let me know if it works?
Once it's confirmed it fixes the issue, I will publish a new version to npm.


GH-43168: [Swift] Add buffer and array builders for Struct type

Rationale for this change
The struct type requires additions/modifications to builders for buffers and arrays.   This is needed in order match functionality with the other supported types.
What changes are included in this PR?
Updates to buffer and array builders for Struct type.
Are these changes tested?
Yes, Array test has been added for the Struct type using the Struct builders
This PR includes breaking changes to public APIs.
The init method for ArrowArray currently does not throw.  This PR will change this behavior and allow the init method to throw.  External code that calls init will need to be updated to catch any errors.

GitHub Issue: #43168

@kou I hope all is well.  I think I have resolved all the issues.  Please review again when you get a chance.


Add buildpacks to build metadata label

Given a group.toml file with the following buildpacks
buildpacks = ["id.buildpacks.one", "id.buildpacks.two", "id.buildpacks.three"]

When exporter is run with -group /path/to/group.toml
Or the group.toml file exists at the default path
Then The buildpacks are added to the io.buildpacks.build.metadata label on the exported image
{"buildpacks": [
  "id.buildpacks.one",
  "id.buildpacks.two",
  "id.buildpacks.three"
], ...}

@ekcasey the group.toml has more information than depicted on this issue. Are we also wanting to include things like version and optional or do we really only want the id?
Example order.toml:
buildpacks = [{id = "buildpack1", version = "version1.1", }, {id = "buildpack2", optional = true}]

@ekcasey the group.toml has more information than depicted on this issue. Are we also wanting to include things like version and optional or do we really only want the id?
Example order.toml:
buildpacks = [{id = "buildpack1", version = "version1.1", }, {id = "buildpack2", optional = true}]

@jromero I think you are right that we do want to include the buildpack versions in this label. I don't think we should include the optional flag, but the list should only include buildpacks that passed detection.

@ekcasey got it. Went ahead and updated the requirements.


Some issues when running mvn package command.

Please answer these questions before submitting pull request

Why submit this pull request?
[X] Bug fix
[ ] New feature provided
[ ] Improve performance

Fixed the warning of 'parent.relativePath' points issue when running the mvn package command.
Fixed the warning of duplicate declaration of plugin issue when running the mvn package command.
Fixed the warning of duplicate declaration of mysql connector jar when running the mvn package command, because of provided scope include test scope.
Fixed the warning of expression ${artifactId} is deprecated issue when running the mvn package command.
Fixed the warning of expression ${version} is deprecated issue when running the mvn package command.

Coverage remained the same at 13.788% when pulling 6bd9975c37b3e5967dff13a90617d5cfdfd6ad49 on peng-yongsheng:fixed/duplicate_plugin into 3acd044d25c9c9adbc2c3073dd34ac2602711c8b on apache:master.


How to get unnormalized key points of  Hand Tracking?

Dear :
Recently, I am learning Hand Tracking with GPU. I can get the coordinates of key points of gestures by modifying the landmarks_to_render_data_calculator.cc, but I find that the coordinates are normalized. Can I get the unnormalized coordinates,Looking forward to your reply

hello, when I learn Hand Tracking with Gpu,i got some questions .Firstly,the tulsi got an error, he told me,An error occurred during the fetch of repository 'local_config_git'...and then when I run the HandTrackingGpu demo ,an error occurred /mediapipe/mediapipe/examples/ios/handtrackinggpu/BUILD:43:1: no such package 'mediapipe/mediapipe/examples/ios': BUILD file not found in any of the following directories.
Could u help me to solve them?

bazel build -c opt --config=ios_arm64 mediapipe/examples/ios/handtrackinggpu:HandTrackingGpuApp
------------------ 原始邮件 ------------------
发件人<EMAIL_ADDRESS>发送时间: 2019年9月26日(星期四) 上午10:54
收件人<EMAIL_ADDRESS>抄送<EMAIL_ADDRESS><EMAIL_ADDRESS>主题: Re: [google/mediapipe] How to get unnormalized key points of  HandTracking? (#134)
hello, when I learn Hand Tracking with Gpu,i got some questions .Firstly,the tulsi got an error, he told me,An error occurred during the fetch of repository 'local_config_git'...and then when I run the HandTrackingGpu demo ,an error occurred /mediapipe/mediapipe/examples/ios/handtrackinggpu/BUILD:43:1: no such package 'mediapipe/mediapipe/examples/ios': BUILD file not found in any of the following directories.
Could u help me to solve them?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

If you know the original image width and height, maybe project the normalized coords back is the simplest way to get original (x,y)?

The large size of the original picture should be obtained, but I don't know the scale of the picture, how can I solve it
------------------ 原始邮件 ------------------
发件人<EMAIL_ADDRESS>发送时间: 2019年9月26日(星期四) 中午11:40
收件人<EMAIL_ADDRESS>抄送<EMAIL_ADDRESS><EMAIL_ADDRESS>主题: Re: [google/mediapipe] How to get unnormalized key points of  HandTracking? (#134)
If you know the original image width and height, maybe project the normalized coords back is the simplest way to get original (x,y)?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

这个还是不行，可以加个qq聊一下吗

776248249
---Original---
From<EMAIL_ADDRESS>Date: Thu, Sep 26, 2019 13:54 PM
To<EMAIL_ADDRESS>Cc: "hejing-maker"<776248249<EMAIL_ADDRESS>Subject: Re: [google/mediapipe] How to get unnormalized key points of  Hand Tracking? (#134)
这个还是不行，可以加个qq聊一下吗
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

The large size of the original picture should be obtained, but I don't know the scale of the picture, how can I solve it
…
------------------ 原始邮件 ------------------ 发件人<EMAIL_ADDRESS>发送时间: 2019年9月26日(星期四) 中午11:40 收件人<EMAIL_ADDRESS>抄送<EMAIL_ADDRESS><EMAIL_ADDRESS>主题: Re: [google/mediapipe] How to get unnormalized key points of HandTracking? (#134) If you know the original image width and height, maybe project the normalized coords back is the simplest way to get original (x,y)? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

There's a ImagePropertiesCalculator that you can get the size of input. Then you can simply use this stream to calculate the image coordinates of the normalized landmarks. Does that solve your problem?

The large size of the original picture should be obtained, but I don't know the scale of the picture, how can I solve it
…
------------------ 原始邮件 ------------------ 发件人<EMAIL_ADDRESS>发送时间: 2019年9月26日(星期四) 中午11:40 收件人<EMAIL_ADDRESS>抄送<EMAIL_ADDRESS><EMAIL_ADDRESS>主题: Re: [google/mediapipe] How to get unnormalized key points of HandTracking? (#134) If you know the original image width and height, maybe project the normalized coords back is the simplest way to get original (x,y)? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
There's a ImagePropertiesCalculator that you can get the size of input. Then you can simply use this stream to calculate the image coordinates of the normalized landmarks. Does that solve your problem?

I found the width and height of the input in the Image_Properties_Calculator code as well as the width and height under the gpu, so how can I print it out? For example, I displayed the eighth key point of hand coordinate in landmarks_to_render_data_calculator. Cc with the following code:
const unsigned char lmIndex = 8;
auto* landmarks_text_render = render_data->add_render_annotations();
auto* landmark_text = landmarks_text_render->mutable_text();
std::string dispText = "LM:";
dispText.append(std::to_string(lmIndex));
landmark_text->set_normalized(true);
dispText.append((std::to_string(landmarks[lmIndex].x() + 0.02))+","+(std::to_string(landmarks[lmIndex].y())));
dispText.append(std::to_string(visualize_depth));
landmark_text->set_display_text(dispText);
landmark_text->set_font_height(0.03);
landmark_text->set_baseline(landmarks[lmIndex].y());
landmark_text->set_left(landmarks[lmIndex].x() + 0.02);

I also have the same problem . How do I display the coordinate for each key points?

I am currently running the mediapipe_multi_hands_tracking_aar_example.
Inside the MainActivity class I am able to obtain the normalized x and y coordinates of the landmarks by using getX() and getY(0 on the received NormalizedLandmarks. However, echoing the question above, how can I obtain the coordinates of the original, unnormalized landmarks and use it in my MainActivity? If this is possible, what do these unnormalized coordinates represent? Are they pixels coordinates? Thank you.


weak memoize passed validateOptions(), drop support for schema as str

Notable Changes
This change aims to reduce extraneous runs of validateOptions(). I believe this will be especially beneficial to loaders. For ex: https://github.com/webpack-contrib/style-loader/blob/master/index.js#L17.
Update: This pr includes a breaking change. However, since schema-utils is primarily used for core webpack libs - this should allow consumers to avoid major bump, since its impl is entirely internal.
Commit Message Summary (CHANGELOG)
PERF: weak memoize passed `validateOptions()`
BREAKING CHANGE: drop support for typeof schema === 'string'

Type

[X] Perf

Issues
N/A
SemVer

[X] Breaking Change (:label: Major)

Checklist

[X] I have signed the CLA
[X] Lint and unit tests pass with my changes
[X] I have added tests that prove my fix is effective/works (if needed)
[X] I have added necessary documentation (if appropriate)
[ ] Any dependent changes are merged and published in downstream modules - N/A

after discussing with @mikesherov, i think the benefit this change offers does not justify risking correctness


Korean translation

First Work
index.html translate by Korean

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


⚠ DesiTorrents has degraded performance

In bf9b3ff, DesiTorrents ($DST) experienced degraded performance:

HTTP code: 200
Response time: 5784 ms

Resolved: DesiTorrents performance has improved in 226165d after 36 minutes.


Update third party libs, frameworks and components

Try to update all the third party software components used by Grisu

do not update Chart.js due to a bug with resizing capabilities!


Themes   tukan/cicada   bootstrap dialog color fix

Result:

sorry for the wrong merge´s. that was not intended. it is only about 4 files !. sorry


The "Scan Photos" task in my LibrePhotos installation does not complete and appears to hang indefinitely.

🐛 Bug Report
📝 Description of issue:
The "Scan Photos" task in my LibrePhotos installation does not complete and appears to hang indefinitely. The task remains in the "waiting" state without showing any signs of progress. Additionally, face recognition does not progress despite photos being displayed in the interface. The UI indicates that the "Scan Photos" process is "In Bearbeitung Scan Photos" (being processed), but no advancement is observed over an extended period.
🔁 How can we reproduce it:

Set up LibrePhotos on a clean Ubuntu Server 22.04 with Docker and Portainer.
Start the "Scan Photos" task within LibrePhotos.
Observe that the task does not proceed and remains in the "waiting" state.

Please provide additional information:

💻 Operating system: Ubuntu Server 22.04
⚙ Architecture (x86 or ARM): Intel n100
🔢 Librephotos version: latest
📸 Librephotos installation method (Docker, Kubernetes, .deb, etc.): Docker using Portainer

🐋 If Docker or Kubernetes, provide docker-compose image tag: latest

📁 How is your picture library mounted (Local file system (Type), NFS, SMB, etc.): local filesystem

Additional context:

Server setup includes only Ubuntu Server 22.04, Docker, and Portainer; no other services or applications installed.
All logs appear normal with no errors indicating the problem.
Issue persists even after attempting a clean install of the project.
No high CPU or memory consumption is observed during the task via top command.
No progress in face recognition scan, with the interface showing photos but no progress in the scan.

Nothing changed here since hours:

no faces:

no cpu load:

117 Test Photos:

I always have the same behavior here

Some Config Screens:

compose file
# DO NOT EDIT
# The .env file has everything you need to edit.
# Run options:
# 1.  Build images on your own machine:
#   build cmd: COMPOSE_DOCKER_CLI_BUILD=1 DOCKER_BUILDKIT=1 docker-compose build
#   run cmd: docker-compose up -d
# https://github.com/LibrePhotos/librephotos-docker/blob/main/librephotos.env

version: "3.8"
services:
  proxy:
    image: reallibrephotos/librephotos-proxy:${tag}
    container_name: proxy
    restart: unless-stopped
    volumes:
      - ${scanDirectory}:/data
      - ${data}/protected_media:/protected_media
    ports:
      - ${httpPort}:80
    depends_on:
      - backend
      - frontend

  db:
    image: postgres:13
    container_name: db
    restart: unless-stopped
    environment:
      - POSTGRES_USER=${dbUser}
      - POSTGRES_PASSWORD=${dbPass}
      - POSTGRES_DB=${dbName}
    volumes:
      - ${data}/db:/var/lib/postgresql/data
    command: postgres -c fsync=off -c synchronous_commit=off -c full_page_writes=off -c random_page_cost=1.0
    healthcheck:
      test: psql -U ${dbUser} -d ${dbName} -c "SELECT 1;"
      interval: 5s
      timeout: 5s
      retries: 5

  frontend:
    image: reallibrephotos/librephotos-frontend:${tag}
    container_name: frontend
    restart: unless-stopped

  backend:
    image: reallibrephotos/librephotos:${tag}
    container_name: backend
    restart: unless-stopped
    volumes:
      - ${scanDirectory}:/data
      - ${data}/protected_media:/protected_media
      - ${data}/logs:/logs
      - ${data}/cache:/root/.cache
    environment:
      - SECRET_KEY=${shhhhKey:-}
      - BACKEND_HOST=backend
      - ADMIN_EMAIL=${adminEmail:-}
      - ADMIN_USERNAME=${userName:-}
      - ADMIN_PASSWORD=${userPass:-}
      - DB_BACKEND=postgresql
      - DB_NAME=${dbName}
      - DB_USER=${dbUser}
      - DB_PASS=${dbPass}
      - DB_HOST=${dbHost}
      - DB_PORT=5432
      - MAPBOX_API_KEY=${mapApiKey:-}
      - WEB_CONCURRENCY=${gunniWorkers:-1}
      - SKIP_PATTERNS=${skipPatterns:-}
      - ALLOW_UPLOAD=${allowUpload:-false}
      - CSRF_TRUSTED_ORIGINS=${csrfTrustedOrigins:-}
      - DEBUG=0
      - HEAVYWEIGHT_PROCESS=${HEAVYWEIGHT_PROCESS:-}
      - FIXPERMISSIONS=${FIXPERMISSIONS:-}
    depends_on:
      db:
        condition: service_healthy

env file
scanDirectory=./librephotos/pictures
data=./librephotos/data
csrfTrustedOrigins=http://chuwi.local:3000
httpPort=3000
tag=latest
gunniWorkers=8
dbName=librephotos
dbUser=docker
dbPass=its_Very_Secret_new_1
DEFAULT_FAVORITE_MIN_RATING=4
dbHost=db
DB_CONT_NAME=db
BACKEND_CONT_NAME=backend
FRONTEND_CONT_NAME=frontend
PROXY_CONT_NAME=proxy
PGADMIN_CONT_NAME=pgadmin
codedir=./librephotos/code
pgAdminLocation=./librephotos/pgadmin
FIXPERMISSIONS=true

Backend Logs
 [X] 0004_alter_user_username_opts
 [X] 0005_alter_user_last_login_null
 [X] 0006_require_contenttypes_0002
 [X] 0007_alter_validators_add_error_messages
 [X] 0008_alter_user_username_max_length
 [X] 0009_alter_user_last_name_max_length
 [X] 0010_alter_group_name_max_length
 [X] 0011_update_proxy_permissions
 [X] 0012_alter_user_first_name_max_length
chunked_upload
 [X] 0001_initial

e
 [X] 0001_initial
 [X] 0002_migrate_from_old_table

contenttypes
 [X] 0001_initial
 [X] 0002_remove_content_type_name
django_q
 [X] 0001_initial
 [X] 0002_auto_20150630_1624
 [X] 0003_auto_20150708_1326
 [X] 0004_auto_20150710_1043
 [X] 0005_auto_20150718_1506
 [X] 0006_auto_20150805_1817
 [X] 0007_ormq
 [X] 0008_auto_20160224_1026
 [X] 0009_auto_20171009_0915
 [X] 0010_auto_20200610_0856
 [X] 0011_auto_20200628_1055
 [X] 0012_auto_20200702_1608
 [X] 0013_task_attempt_count
 [X] 0014_schedule_cluster
 [X] 0015_alter_schedule_schedule_type
 [X] 0016_schedule_intended_date_kwarg
 [X] 0017_task_cluster_alter
sessions
 [X] 0001_initial
use SECRET_KEY from file
167 static files copied to '/code/librephotos/static'.
use SECRET_KEY from file
llm: service starting
thumbnail: service starting
face_recognition: service starting
image_captioning: service starting
clip embeddings: service starting
Your cache has been cleared!
use SECRET_KEY from file
20:15:45 [Q] INFO Enqueued [DjangORM] 134
20:15:45 [Q] INFO Enqueued [DjangORM] 135
Running backend server...
production backend starting
use SECRET_KEY from file
[2024-03-06 20:15:46 +0000] [103] [INFO] Starting gunicorn 21.2.0
[2024-03-06 20:15:46 +0000] [103] [INFO] Listening at: http://<IP_ADDRESS>:8001 (103)
[2024-03-06 20:15:46 +0000] [103] [INFO] Using worker: gevent
[2024-03-06 20:15:46 +0000] [105] [INFO] Booting worker with pid: 105
[2024-03-06 20:15:46 +0000] [106] [INFO] Booting worker with pid: 106
[2024-03-06 20:15:46 +0000] [107] [INFO] Booting worker with pid: 107
[2024-03-06 20:15:46 +0000] [108] [INFO] Booting worker with pid: 108
[2024-03-06 20:15:46 +0000] [111] [INFO] Booting worker with pid: 111
[2024-03-06 20:15:47 +0000] [112] [INFO] Booting worker with pid: 112
[2024-03-06 20:15:47 +0000] [113] [INFO] Booting worker with pid: 113
[2024-03-06 20:15:47 +0000] [114] [INFO] Booting worker with pid: 114
use SECRET_KEY from file
use SECRET_KEY from file
use SECRET_KEY from file
use SECRET_KEY from file
use SECRET_KEY from file
use SECRET_KEY from file
use SECRET_KEY from file
use SECRET_KEY from file
20:15:55 [Q] INFO Q Cluster sweet-bakerloo-skylark-april starting.
20:15:55 [Q] INFO Process-7a51391a73e540dc929e6f47054589b4 ready for work at 151
20:15:55 [Q] INFO Process-4c0ea8e06aa54e1faf03fa7e7f8778ae monitoring at 152
20:15:55 [Q] INFO Process-dffa6883f62c4704ad7ffe5a6b688df7 guarding cluster sweet-bakerloo-skylark-april [DjangORM]
20:15:55 [Q] INFO Process-27d1d28d08bd404eacf5a20043169fde pushing tasks at 153
20:15:55 [Q] INFO Q Cluster sweet-bakerloo-skylark-april [DjangORM] running.
20:15:55 [Q] INFO Process-7a51391a73e540dc929e6f47054589b4 processing carpet-juliet-kansas-sweet 'api.image_similarity.build_image_similarity_index'
<IP_ADDRESS> - - [2024-03-06 20:15:55] "POST /build/ HTTP/1.1" 200 139 0.000925
20:15:55 [Q] INFO Process-7a51391a73e540dc929e6f47054589b4 processing maryland-london-don-october 'api.image_similarity.build_image_similarity_index'
<IP_ADDRESS> - - [2024-03-06 20:15:55] "POST /build/ HTTP/1.1" 200 139 0.000747
20:15:55 [Q] INFO Processed 'api.image_similarity.build_image_similarity_index' (carpet-juliet-kansas-sweet)
20:15:55 [Q] INFO Processed 'api.image_similarity.build_image_similarity_index' (maryland-london-don-october)
Unauthorized: /api/persons/
Unauthorized: /api/searchtermexamples/
Unauthorized: /api/user/1/
Unauthorized: /api/albums/user/list/
Unauthorized: /api/albums/thing/list/
Unauthorized: /api/imagetag
Unauthorized: /api/serverstats
Unauthorized: /api/dirtree/
Unauthorized: /api/user/
Unauthorized: /api/jobs/
Unauthorized: /api/albums/place/list/
/usr/local/lib/python3.11/dist-packages/rest_framework/pagination.py:200: UnorderedObjectListWarning: Pagination may yield inconsistent results with an unordered object_list: <class 'api.models.person.Person'> QuerySet.
  paginator = self.django_paginator_class(queryset, page_size)
Unauthorized: /api/sitesettings
Unauthorized: /api/rqavailable/
Unauthorized: /api/storagestats

db logs
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.
The database cluster will be initialized with locale "en_US.utf8".
The default database encoding has accordingly been set to "UTF8".
The default text search configuration will be set to "english".
Data page checksums are disabled.
fixing permissions on existing directory /var/lib/postgresql/data ... ok
creating subdirectories ... ok
selecting dynamic shared memory implementation ... posix
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting default time zone ... Etc/UTC
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... ok
syncing data to disk ... ok
Success.

When a job becomes stuck, it typically indicates that it has encountered an error and we failed to capture it accurately for display. To initiate another job, simply remove the stuck entry from the list.
I still think that you hit some kind of error. Navigate to "./librephotos/data" directory where you'll find a "logs" folder containing several log files. Please check if any of these logs contain error messages that might shed light on the issue.
It's great to hear that you're using a mini PC with an N100! I was also considering them as a potential home server option last week :smile:

Thank you for your response.
I'll take a look and follow your guidance.
I operate two mini servers as Docker hubs.
One is equipped with 32GB of RAM and the other with 16GB.
Both are perfect for my needs.
The second server functions as a PhotoLibre server, and the first one, with 32GB of RAM, serves Nextcloud, Paperless-ngx, Jellyfin, and a few other applications. Everything runs smoothly.

/var/log looks pretty
root@5d59e1c5e515:/var/log# ll
total 560
drwxr-xr-x 1 root root     79 Feb 26 18:29 ./
drwxr-xr-x 1 root root     19 Nov 28 02:06 ../
-rw-r--r-- 1 root root  19942 Feb 26 18:29 alternatives.log
drwxr-xr-x 1 root root     60 Feb 26 18:28 apt/
-rw-r--r-- 1 root root  57835 Nov 28 02:03 bootstrap.log
-rw-rw---- 1 root utmp      0 Nov 28 02:03 btmp
-rw-r--r-- 1 root root 485169 Feb 26 18:29 dpkg.log
-rw-r--r-- 1 root root      0 Nov 28 02:03 faillog
-rw-r--r-- 1 root root    605 Feb 26 18:29 fontconfig.log
-rw-rw-r-- 1 root utmp      0 Nov 28 02:03 lastlog
-rw-rw-r-- 1 root utmp

db Container logs:
root@fee76bc8344b:/var/log# ls -l
total 44
-rw-r--r-- 1 root root      6340 Feb 21 22:51 alternatives.log
drwxr-xr-x 1 root root        60 Feb 21 22:50 apt
-rw-rw---- 1 root utmp         0 Feb 11 00:00 btmp
-rw-r--r-- 1 root root     33616 Feb 21 22:51 dpkg.log
-rw-r--r-- 1 root root         0 Feb 11 00:00 faillog
-rw-rw-r-- 1 root utmp         0 Feb 11 00:00 lastlog
drwxrwxr-t 2 root postgres     6 Feb  8 12:32 postgresql
-rw-rw-r-- 1 root utmp         0 Feb 11 00:00 wtmp
root@fee76bc8344b:/var/log# cat faillog
root@fee76bc8344b:/var/log# cat lastlog
root@fee76bc8344b:/var/log#

The logs look good; I couldn't find any errors. Additionally, your suggestion helped. Removing the entry worked, and a subsequent scan successfully detected images. Amazing! Thank you!

No Faces:

No process

now it works. i do nothing but it works. Maybe this is the key: do nothing :D


Openssl 3.0.5+quic

Checklist

[ ] documentation is added or updated
[ ] tests are added or updated

Not worried about the two failures. CIFuzz always seems to fail, and the other is an upstream issue.


Add tests

You have example tests in the README, but none in the repository?

@dcousens
Actually it uses markdown-code-blocks to extract tests directly from readme and execute them (see command "test": "markdown-code-blocks -t javascript < README.md | node")

That is awesome, especially for a small module.


fix: handle CSS Modules as modules

Description
This PR changes how CSS Modules are handled in Vite.
Previously, CSS Modules were bundled at every entry-point via postcss-modules. This caused issues, duplicating CSS Module dependencies, and preventing Vite plugins from accessing dependencies.
With this PR, CSS Modules are now resolved & bundled by Vite/Rollup by compiling them into individual JS modules.
fixes https://github.com/vitejs/vite/issues/15683
fixes https://github.com/vitejs/vite/issues/7504
fixes https://github.com/vitejs/vite/issues/10079
fixes https://github.com/vitejs/vite/issues/10340
fixes https://github.com/vitejs/vite/issues/14050 (this one is because I don't use Rollups dataToEsm)
fixes https://github.com/vitejs/vite/issues/16074
fixes https://github.com/vitejs/vite/issues/16075
To achieve this, I created a plugin that handles CSS Modules here: https://github.com/privatenumber/vite-css-modules
I realize this approach is somewhat unconventional, but I wanted a way to offer this change both as a patch for users unable to upgrade Vite, and as an integration into Vite core.
It was also easier to scope this logic in a separate repo with tests. And since the previous CSS Modules implementation was an external package, I figured this isn't too far fetched.

Additional context

LightningCSS is ready to go, but I haven't implemented full parity with postcss-modules yet:

[x] getJSON
[x] globalModulePaths
[x] localsConvention

TBH I think these options should be removed in the future, but I can implement them for parity if this is something we want.

What is the purpose of this pull request?

[x] Bug fix
[ ] New Feature
[ ] Documentation update
[ ] Other

Before submitting the PR, please make sure you do the following

[x] Read the Contributing Guidelines, especially the Pull Request Guidelines.

[x] Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.

[x] Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).

[ ] Update the corresponding documentation if needed.
I have not updated documentation yet. Hoping to receive feedback first.

[x] Ideally, include relevant tests that fail without this PR but pass with it.

Nice! Thanks for working on this @privatenumber. I'd like to see what other maintainers think about the separate package. My first impression is that CSS Modules are important enough for this plugin to live directly in Vite core. It will be good to avoid sync issues, for example with internals of Vite you are duplicating.

/ecosystem-ci run

astro is failing because it expects the exact CSS Module hash. I'm not sure if it's expected or necessary for the hashed class to be deterministic. What do you think?

vite-plugin-vue is failing because I didn't implement localsConvention yet (importing kebab-case classnames as camelCase). Will look into this.

Currently not sure why nx, rakkas, and unocss are failing—it doesn't seem related to CSS Modules but I'll dig deeper later.

nx is already failing in main. I think you need to merge main into this PR and the unocss and rakkas issues will be gone. See https://github.com/vitejs/vite/pull/16011
cc @bluwy about the Astro question.

/ecosystem-ci run

Awesome!
I prefer having it directly in Vite core for the same reason with @patak-dev.

(this one is because I don't use Rollups dataToEsm)

You can use includeArbitraryNames: true option for that.
But generating an export using arbitrary names feature will make it impossible to transpile the bundle to lower versions. For example, if you add .if {} in playground/css/mod.module.css and make that CSS file in a separate chunk (e.g. dynamic import that file), an error will happen.

TBH I think these options should be removed in the future, but I can implement them for parity if this is something we want.

getJSON and globalModulePaths are rarely used, but localsConvention is used a lot.
I think we need to support localsConvention at least.
I'm not sure if setting globalModulePaths makes sense in the first place. Should this option be set as /(?<!\.module)\.css$/ so that it follows our naming convention?
If it's not complicated, I think we should support getJSON.

/ecosystem-ci run

/ecosystem-ci run

@bluwy

If vite-css-modules could provide an abstraction that's perhaps more generic

The generic parts of CSS Modules are already provided as packages by the CSS Modules team (same packages that Webpack's css-loader uses).
But, if I were to implement CSS Modules as a Rollup plugin, I'd do it differently so it's more compatible with other plugins to transform the CSS. But for the purposes of patching Vite's CSS Modules behavior without breaking change, I was constrained to implement it this way. That said, this plugin is only compatible with Vite. I decided to implement it as a separate package first because the primary purpose of the plugin is for others to use/test this fix without upgrading Vite or waiting for this PR.
For the next major, I would love to make a proposal towards how CSS Modules should be implemented as a Rollup plugin. I've even secured the rollup-plugin-css package name :)

However, If we keep it that way, maybe it makes more sense to upstream this feature directly to postcss-modules? (if it makes sense)

Can't because postcss-modules targets a different use-case where there is no other bundler in the pipeline. It implements its own bundler, creating a black-boxed CSS Module bundle separate from Rollups, which leads to the bugs (e.g. duplicated dependencies, other Vite plugins not being able to access composed CSS Modules).

I've implemented getJSON and globalModulePaths. This PR should be ready!
Can you run ecosystem-ci?

/ecosystem-ci run

Can't because postcss-modules targets a different use-case where there is no other bundler in the pipeline. It implements its own bundler, creating a black-boxed CSS Module bundle separate from Rollups, which leads to the bugs (e.g. duplicated dependencies, other Vite plugins not being able to access composed CSS Modules).

I guess I was thinking postcss-modules could expose a separate technique where it can assume a bundler in the pipeline. The name itself doesn't mean it has to be a PostCSS plugin, plus reading the alternative implementation right (vite-css-modules), it still relies on postcss to process internally. But of course if it makes sense as a separate package, that's also good as an exploration phase.
Correct me if I'm wrong, but I'm thinking an abstraction could look like that after we call compileCSS() on the CSS module, we could use an API to later process those and return the final CSS and JS? Something like:
const { code: css } = await compileCSS(id, css)

if (isModule) {
  const { code: newCss, js } = await compileCSSModule(css, modulesConfig) // uses postcss or lightningcss
  // ...
}

Also, I think this PR breaks the experimental preprocessCss API as it no longer returns a module, but I've personally not seen usage that relies on this. If we want to fix this, we have to move the CSS modules handling inside compileCSS.

It seems plugin-vue is failing because the source map is broken. sourcesContent should be the content of the vue file but it's an empty string.
https://github.com/vitejs/vite-ecosystem-ci/actions/runs/8091723574/job/22111257321#step:8:871

But generating an export using arbitrary names feature will make it impossible to transpile the bundle to lower versions. For example, if you add .if {} in playground/css/mod.module.css and make that CSS file in a separate chunk (e.g. dynamic import that file), an error will happen.

To handle this problem, I think we need a new option to make the feature (#14050) opt-in.

@sapphi-red Just implemented source map support. Would you mind running ci again?

But generating an export using arbitrary names feature will make it impossible to transpile the bundle to lower versions. For example, if you add .if {} in playground/css/mod.module.css and make that CSS file in a separate chunk (e.g. dynamic import that file), an error will happen.

I haven't looked into this yet, but will look into it soon.

/ecosystem-ci run

CI / Build&Test: node-20, ubuntu-latest is failing due to a WebSocket error. I think re-reunning should pass it.
It seems both nx and analogjs are failing on main. I'm not sure if I understand the rakkas errors—is it relevant to these changes?

@sapphi-red

But generating an export using arbitrary names feature will make it impossible to transpile the bundle to lower versions. For example, if you add .if {} in playground/css/mod.module.css and make that CSS file in a separate chunk (e.g. dynamic import that file), an error will happen.

I looked into this, and it doesn't seem like a problem in my approach: https://stackblitz.com/edit/vitejs-vite-hpdg7d?file=src%2Fmain.js
Likely because I only declare safe variable names via Rollup's makeLegalIdentifier.
I do something like:
const safeIf = 'hash';
export { safeIf as 'if' }

This is optimized so it's only done if the safe version of the name is different from the original:
https://github.com/privatenumber/vite-css-modules/blob/c02aefe58d9343058c3e0c738716567b3ffa0903/src/plugin/generate-esm.ts#L42-L44

I'm not sure if I understand the rakkas errors—is it relevant to these changes?

I guess it is. IIUC this PR changes the generated module graph and that might be affecting rakkas. I'm not sure which side the fix should be done on though.
I guess https://github.com/rakkasjs/rakkasjs/commit/73f218d24e2879ad3bdf836bf04aa9b584c7106b is the related commit.

rakkas should pass now :)

@sapphi-red

But generating an export using arbitrary names feature will make it impossible to transpile the bundle to lower versions. For example, if you add .if {} in playground/css/mod.module.css and make that CSS file in a separate chunk (e.g. dynamic import that file), an error will happen.

I looked into this, and it doesn't seem like a problem in my approach: https://stackblitz.com/edit/vitejs-vite-hpdg7d?file=src%2Fmain.js
Likely because I only declare safe variable names via Rollup's makeLegalIdentifier.
I do something like:
const safeIf = 'hash';
export { safeIf as 'if' }

This is optimized so it's only done if the safe version of the name is different from the original: https://github.com/privatenumber/vite-css-modules/blob/c02aefe58d9343058c3e0c738716567b3ffa0903/src/plugin/generate-esm.ts#L42-L44

Here's an example that fails (a class name including -): https://stackblitz.com/edit/vitejs-vite-ccwcai?file=package.json

Glad all tests are passing!

Here's an example that fails (a class name including -): stackblitz.com/edit/vitejs-vite-ccwcai?file=package.json

FYI this is a different error from https://github.com/vitejs/vite/issues/14050.
It doesn't happen in dev mode in Chrome. But in build mode, it happens because esbuild catches it because it thinks the target may not support it. I'm not sure if this is always necessary since most modules are internal and processed by Rollup.
It can be turned fixed either by passing in build.target: 'esnext' in the user config (demo), or by passing in arbitrary-module-namespace-names in supported on Vite's side (maybe just when transforming internal modules?).

It can be turned fixed either by passing in build.target: 'esnext' in the user config (demo), or by passing in arbitrary-module-namespace-names in supported on Vite's side (maybe just when transforming internal modules?).

It would be a problem when:

a library uses css modules
the file in the library uses a class name including -
the library uses the default export of css modules (does not use the named exports)
the css module chunk is separated in a different chunk
the user wants to support browsers that doesn't support arbitrary namespace names

Without this PR, users can do that. But with this PR, users can no longer do that. Because [a] without setting build.target: 'esnext' or esbuild.supported['arbitrary-module-namespace-names']: true, the build will fail [b] even with setting either of them, the output includes "arbitrary namespace names" syntax (repro: dist/assets/style.module-CkZcHCk9.js contains export{t as default,e as"foo-bar"};) and the code won't run.

That's a good point. This would be breaking as is.
I'm open to only enabling that feature for certain build targets. But I'm also curious if we can explore the avenue of enabling arbitrary-module-namespace-names within Vite.
In esbuild, it's declared as an ES2022 feature, and the spec is referenced in the old compat table.
The feature has landed in:

Node 16 (reached EOL Sep 2023)
Chrome 90
Firefox 87
Safari 14.1 (I got the earliest release version by doing a find for -macOS-)

The unsupported browsers only account for 1% in the browser coverage. The probability of an app that uses CSS Modules and code-splits at CSS Modules (hence creating chunks with string export names), that also needs to run on these outdated browsers becomes even lower. Do you think we can consider cutting this tiny corner?
If not, I can update to only enable string export names based on build.target, leaving #14050 to be only fixed when the build target is raised.

I'm also curious if we can explore the avenue of enabling arbitrary-module-namespace-names within Vite.

I think we shouldn't do that. Enabling it will cause browsers that does not support arbitrary module namespace names but specified in build.target to error in parse phase. That means the error cannot be caught in a normal way. Also users cannot notice that unless they run build + preview and check with the old browser.
By bumping the lowest modern chunk supported version / default build.target value, we can assume arbitrary module namespace names support. So after Vite 6, we can do that.

I can update to only enable string export names based on build.target

I wonder if that is a bit too magical. But I'm still fine with it. I guess we can check it by whether esbuild throws an error.

Fixed: https://stackblitz.com/edit/vitejs-vite-t2cjqp?file=package.json

Moving this to the 5.3 milestone. We'd like to keep 5.2 as a small release for now, and keep the larger changes to 5.3. We also need to discuss this approach in the next team meeting before going forward. Personally for me, I'd like to see some of my concerns here addressed.

I guess I was thinking postcss-modules could expose a separate technique where it can assume a bundler in the pipeline.

Would like to move away from using postcss-modules for the following reasons:

It's not maintained.

It caters to a fundamentally different use-case. It was not designed to work with bundlers, and trying to make it do so has led to the issues this PR is trying to fix.

It has APIs that don't make sense in the context of using a bundler (e.g. getJSON, globalModulePaths, etc ). For the next major, I'm excited to discuss removing many of them to simplify how CSS Modules is implemented.

Even if we can make changes to it, the breaking changes would disrupt current users who are using it as intended (e.g. without a bundler).

Don't mean to be too critical, but the implementation is convoluted. It's a PostCSS plugin that implements a half-baked bundler which processes each module by calling PostCSS again. This is akin to a Babel plugin that calls Rollup with the Rollup Babel plugin—it feels very hacky.

The name itself doesn't mean it has to be a PostCSS plugin, plus reading the alternative implementation right (vite-css-modules), it still relies on postcss to process internally. But of course if it makes sense as a separate package, that's also good as an exploration phase.

Yeah, the core packages released by the CSS Modules team are PostCSS plugins so it's necessary. But in Lightning mode, it doesn't use PostCSS.

Also, I think this PR breaks the experimental preprocessCss API as it no longer returns a module, but I've personally not seen usage that relies on this. If we want to fix this, we have to move the CSS modules handling inside compileCSS.

Ah yeah, if preprocessCss is a public API (don't see it documented), it would be breaking. But I think this is how it should be. I think part of the fix and predictability of this new approach was moving CSS Modules from pre-processing to post-processing. Deferring the CSS Module compilation to the final step will make it easier for other CSS plugins (e.g. 3rd party) to insert itself into the pipeline.
Essentially, compiling CSS Modules in the pre-processing step was probably not the best decision.

Correct me if I'm wrong, but I'm thinking an abstraction could look like that after we call compileCSS() on the CSS module, we could use an API to later process those and return the final CSS and JS? Something like:
const { code: css } = await compileCSS(id, css)

if (isModule) {
  const { code: newCss, js } = await compileCSSModule(css, modulesConfig) // uses postcss or lightningcss
  // ...
}

I think it's better to abstract CSS Module compilation into its own plugin. It processes CSS, but it's quite different from other CSS processors in that it outputs JS.
Kind of like with SVGs... there are SVG optimization plugins and there are SVG-to-JS plugins, but you wouldn't want to couple them together as converting the SVG to JS (SVG string or an asset URL) is really an interfacing concern rather than a processing one.
It also has quite a bit of complexity, and it even returns a source map. Separating the concerns will improve maintainability & testability (avoiding shoe-horning tests like this).

Thanks for taking the time to respond! Your explanation about postcss-modules makes sense to me. I agree that some of its API doesn't quite fit for bundlers and we could revisit them in the next major. If we do move to a new package, I'd be careful to not dismiss its contribution to Vite and the ecosystem though. The author may have their own reasons.

Re preprocessCss, I can see that handling CSS modules isn't technically a preprocess step, so if the rest are fine with this breaking change, we can go ahead instead.

I think making CSS modules its own plugin and as a post plugin makes sense. My remaining concern is that I'm not sure if this PR's implementation (import { cssModules } from 'vite-css-modules') is the right abstraction or "the cut-off point between Vite and third-party package".
I'd prefer if the CSS modules plugin is written in Vite instead, like mentioned by patak and sapphi. But not entirely inlining vite-css-modules inside Vite, rather, we keep the same relationship as postcss-modules. e.g. Use a third-party package to do the heavy lifting generically, and create a Vite plugin to link everything up. For example, if it can expose
// rough idea (not exactly proposing this API)
function compileCSSModule(css: string, options: PostcssModulesConfig | LightningcssModulesConfig):
  Promise<{ code: string, css: string, exports: Record<string, any>, map: SourceMap }>

That way we can own the CSS modules plugin, and the heavy-lifting/tests are done third-party. I'd hold off implementing this first though to hear what @patak-dev and @sapphi-red think about this. If they prefer to inline everything into Vite, then I can't argue with that too 😅

@privatenumber, we really appreciate you looking into this problem and all the work you already have done here. It will be a big improvement for everyone. This is a big change though. I understand that you feel this was going to be easier to get merged but the discussion so far has been conducted well for the way Vite works and IMO is required to land this correctly with no disruption to the ecosystem and with our eyes on the long term maintainability of the project. I hope you don't get too frustrated by what is the regular flow when adding a new dependency, and we can keep working together. We already decided that this is too big of a change for Vite 5.2, as we want to release the next minor quickly and then focus bigger changes in 5.3 (that currently only have two PRs, this one and the Environment API). Vite 5.3 will be released in around 2 months so there is no rush at this point.
Given the discussion above, I'm leaning to pulling in vite-plugin-css to Vite as being the best option. I hope that could happen for Vite 5.3, if you'd find that a good idea too. I'd like to also hear what @sapphi-red thinks too before though.

Thanks for letting me know the target release is 2 months away—I will plan to follow up with the refactor in a few weeks.
To clarify, I'm not asking for it to be released (I'm unblocked via my plugin). Just want to ask for the work to be divided into incremental PRs. Specifically, it would be helpful if there could be a feature branch within Vite, allowing me to merge this PR and open follow-up PRs to it. I can open follow-up PRs now but it would be within my fork.
Also, I think we've reached a consensus on pulling vite-plugin-css into Vite. I think @bluwy was asking about the implementation detail of whether to abstract out the compilation step to a util package, but I explained the concerns are too coupled.

We have the same issue with the Environment API. What we are doing with it is have an umbrella PR (see https://github.com/vitejs/vite/pull/16129), where we are pushing changes from other PRs (see https://github.com/vitejs/vite/pull/16137). We also commit directly to it when we don't need a separate space to discuss or trigger ecosystem-ci. You could send a new PR, point this one to it and merge it. And then start sending new PRs against it until it is ready.
Rolldown is now using https://graphite.dev/blog/stacked-prs. We'll discuss with them to see how it is working after a while. Maybe we could adopt something similar.

@privatenumber I figured to draft my idea in a local branch to showcase the abstraction I was thinking of. I have a modified version of vite-css-modules under packages/css-modules which I don't mind if you want to port some things back to your package.
I thought it was a quick 30min sketch, but I've spent several hours now polishing it up 😅 It kinda works but tests are failing, but I'm not pushing for the branch over-the-line, only mainly to get the idea of the state of this PR so far. The bright side is that I understand some aspects of vite-css-modules like loadExports, fallback load(), ?.module.css, exportAs set, getJSON/.resolved etc and how postcss-modules options made it complex 😄
Happy to collaborate on it though if you'd like, or help take over if the PR is taking a while. Like patak mentioned, we'd like a get it right when making a big change to Vite as we're depended by many frameworks.

@bluwy
Wow thank you so much 🙌
I appreciate you trying to better understand the problems by getting involved.
Happy to collaborate! Do you have a preferred way for us to chat?
I'm determined to get this right as well. And I'm not pressed to get this released because of my plugin.
I just wanted to merge to a local branch like you have (Stacked PR approach patak mentioned).

@patak-dev
Sorry I'm not sure if I follow. Which branch do you want me to change this PR against?

Sorry I'm not sure if I follow. Which branch do you want me to change this PR against?

@bluwy maybe you could create a new feat/revamped-css-modules (it can start from main and you PR it without any changes to have the PR to discuss) and then this PR can be merged against it and used as a base for future work? Future PRs can be made against that branch until the feature is ready to be merged.

Happy to chat about it at the Vite Discord server #contributing channel! I imagine there will be a lot of back-and-forth, so that will help here.
I think personally I'd hold off having a feature branch to merge in first. I think there's some topics to talk about from this current implementation, like "post-load fallback", "css modules as post-plugin", "different abstraction api", etc. That will be hard to change from a feature branch if we merge it in. The code may look very different after subsequent PRs, but a feature branch is still definitely on-the-table once we have a good direction of the implementation later.

I only went through the surface, but the idea makes sense to me. Awesome work!
Just in case, let me mention Remix's use case of css module since it might not be covered by ecosystem ci.
I think what Remix does goes like this:
(the approach is based on solid-start at that time, but it looks like similar code now lives in vinxi.)
collect css module's css by intercepting `transform` hook
https://github.com/remix-run/remix/blob/6ad886145bd35298accf04d43bd6ef69833567e2/packages/remix-dev/vite/plugin.ts#L1269-L1272
https://github.com/nksaraf/vinxi/blob/00d68f0e9711b44cc5e011588e52803bf8160b91/packages/vinxi/lib/plugins/css.js#L33-L37
      async transform(code, id) {
        if (isCssModulesFile(id)) {
          cssModulesManifest[id] = code;
        }

include css module's css code in SSR style head to avoid FOUC
https://github.com/remix-run/remix/blob/6ad886145bd35298accf04d43bd6ef69833567e2/packages/remix-dev/vite/styles.ts#L77-L79
https://github.com/nksaraf/vinxi/blob/00d68f0e9711b44cc5e011588e52803bf8160b91/packages/vinxi/lib/manifest/collect-styles.js#L173
        let css = isCssModulesFile(dep.file)
          ? cssModulesManifest[dep.file]
          : (await viteDevServer.ssrLoadModule(dep.url)).default;

Does this idea still work with new js module centric approach or does it need to be written differently?
Or maybe is there entirely different alternative if astro, rakkas, etc... are not using this transform interception approach?
Hopefully I'm not missing what Remix actually does. Maybe it's better to confirm with Remix and Vinxi side.

Thanks for sharing @hi-ogawa. Yeah since this PR moves the CSS modules handling as a post-plugin, I think that usecase might cause cssModulesManifest[id] = code; to get the incorrect CSS (which is before CSS modules is processed).
Your edit seems like a good way around it, I would agree that retrieving the CSS for SSR currently is quite clunky, because Vite's API is made around the assumption that files are lazily processed. For reference, here's how Astro (uses links) and SvelteKit (uses ?inline) handle CSS modules FOUC.
Since there's an implementation today that relies on how CSS modules are processed, I wouldn't mind moving the CSS modules handling back as a normal plugin to not break this for now, and in the next major, we could move it as a post plugin.

Also, I've talked with privatenumber recently about where to go from here. I've created a new feat/revamped-css-modules feature branch that's squash-merged from this PR and we'll continue iterating from there. I'll be helping around to get this feature finished by Vite 4.3.

Hey just comming around this issue, will this PR also solve the issue that you get a full page reload on an update of a module.css file? I first thought that this is a vike issue, but it seems to be a vite server render issue?

I'm not sure what problem you're describing but you can confirm yourself with privatenumber/vite-css-modules.
The work in this PR has paused.

An update on my end: I really wanted to pick this back up one day but there's a lot still to get done and verifying that it's compatible to as before (as close as possible). Among the few things I want to check:

Last we discussed, there's slight differences in how the "imported" CSS modules variables were inlined. This affected Vite's builtin resolving to be able to retrieve the referenced file, but we probably don't want this resolving behaviour exposed.
Making CSS and CSS modules handling a separate two-step process doesn't work well for lightningcss. It wants to control the entire transform and do it once. Splitting it out has caveats, like invalid CSS-modules-specific syntax parsing if css modules option is not turned on, and potentially perf implications. We need to figure out some consistency or tradeoffs here.
I wanted a new internal package for this different CSS modules handling. We could punt that off, but ideally still have the code modularize enough so that the domain-specific logic is all located in one place.
I'm still a bit worried about integrating too many domain-specific code for CSS modules here. Part of how Vite is structured is that outsources well-scoped work as necessary, e.g. rollup, esbuild, postcss, postcss-import, plugin-commonjs, etc.

Sorry for causing the PR to be stale. The chores laying in front here has caused me to not prioritize this in a while 😅


Inconsistent font rendering/sizing

The LCUI example helloworld shows inconsistent font sizes when updating the text.
Reproduction Steps:

Build current develop branch
Build examples in test/
Run the built helloworld
Repeatedly click the Change button

Screenshots and GIFs

LCUI version: branch develop commit 402bc031b424923b89feea390a84a2c15a9b1fdb
OS and version: Linux 4.15.1
Build tools: gcc (GCC) 7.3.0
Libraries (taken from LCUI_LIBS in the generated Makefile):

libxml2 2.9.7
freetype 2.9
libx11 1.6.5
libpng 1.6.34
zlib 1.2.11
libjpeg-turbo 1.5.3

Fixed.
https://github.com/lc-soft/LCUI/commit/9995b23bebb643cf1e74c544922db5028ef4eae7#diff-e0a052a143a1fd2418b69fd5fcf24ee2R58
LCUI_TextStyle::has_pixel_size is not initialized before it is used.
void TextStyle_Init( LCUI_TextStyle data )
{
	data->has_style = FALSE;
	data->has_weight = FALSE;
	data->has_family = FALSE;
+	data->has_pixel_size = FALSE;
	data->has_back_color = FALSE;
	data->has_fore_color = FALSE;


Add Gemini Logo

The icon I want is:

Name: Gemini

URL: https://gemini.google.com/

Link to icon: https://www.freelogovectors.net/gemini-logo-chatbot-01/

Vector version of the logo: https://github.com/ohmschrodinger/Hacktober-Fest-2024/blob/main/gemini.svg

@edent  I've read through the https://github.com/edent/SuperTinyIcons/blob/master/CONTRIBUTING.md and I've committed the changes to my forked repo. Should I go ahead and send a PR? Is that okay?

In case you need a reference, here’s the link to my forked repository:
https://github.com/ohmschrodinger/SuperTinyIcons/tree/GeminiLogo?tab=readme-ov-file

It's done. do i need to make any other changes?

I can't see it any more. Send it as a PR to this repository.


Use Atom Docks

Atom have introduced docks in 1.17, the side pane has gained round buttons to show/hide dock. Plugin would benefit from using it

@Yanpas  Hi, maybe you can try this newer plugin which used docker.
https://atom.io/packages/structure-view

Looks nice, anyway I've switched to vscode


chore(package): update got to version 11.1.1

Coverage remained the same at 88.217% when pulling 60098b16c4115ef78b2937f04884946388bb30ad on greenkeeper/got-11.1.1 into 010edba1f48fe318e7d74c9febf9192b77c34a7d on master.


Branches

Added branches listing, creating, deleting.
Updated repos to return an object
Make Branches pretty much act like repos
Updated files/contents to be able to read from branches (still untested)
Added eslint 😄

Note that branch create/delete requires more permissions than the token we've been using has.  it requires repo permissions as well.


Add redirect to fix misprinted kit list document

Summary
There was a misprint on the kit list.
Code review
Testing

[ ] applied the configuration locally
[ ] manually validated the new behaviour

Links
https://docs.google.com/document/d/1N7mYdnkpsnXOb0nHRRT2rYhcLqEnq8EndQXVNaE884E/edit?usp=sharing

@RealOrangeOne especially as this was fixing an issue due to a link not being checked before being printed, please could we check that this actually works? Both that it's what was in fact on the sheets (my recollection of which was that it had a trailing slash) and that it does indeed direct users to the right link.

$ curl https://sr-proxy/kit/return/ -ksI | grep location
location: https://sr-proxy/docs/kit/return/


How can we generate token while logging in user?

Can you add a sample login action in documentation to help how we can generate token for authentication which can later on be validated through this?

Hi @muhammadshakeel. JWT is used in APIs to check income requests for valid signature.
How do you want to use it?

We need to use it for our api which will be used from our mobile app. Users
will login in response we assume to generate a jwt token for each user and
then every other request will contain this token to identify a valid user.
Am I wrong with Jwt?
On Apr 11, 2016 9:13 PM, "Damir"<EMAIL_ADDRESS>wrote:

Hi @muhammadshakeel https://github.com/muhammadshakeel. JWT is used in
APIs to check income requests for valid signature.
How do you want to use it?
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/damirka/yii2-jwt/issues/4#issuecomment-208430154

You are right. Just had to be sure.
So what is unclear about it? There is no common way of doing it so I can only suggest you to make an /auth action for example and return token in JSON (or whatever) response.
<?php

class AuthController extends APIController
{
    public function actionAuth()
    {
        // some user identifying logic in here
        // ...
        return ['token' => $user->getJWT()];
    }

    // other actions or methods
    // ...
}

Thanks alot @damirka things are very much clear now.


Added active section and active LL tab [#160284706]

NOTE: to allow the UI model to have a reference to a section in the problem model I had to create an identifier for each section.  For the built in JSON the type doubles as the identifier for now.

@kswenson I changed to use an index into the section array and then added a read only canvas to the left nav to display the section contents and finished by adding aria tags to the tabs for accessibility.


chore: Use personal GH token to release mrack

When branch protection is enabled only real
user (not gh-actions as it is bot) can push
to the main branch when there is Pull Request
required and approvals for particular PR.
With exception added to the users which can bypass the protection rules we should be able to release
with personal GH token generated for the user.
Signed-off-by: Tibor Dudlák<EMAIL_ADDRESS>

Yup i need to test it somehow


If SnapToProcess is used, bring that process to front automatically

If SnapToProcess is used, bring that process to front automatically.
Also provide cmd option for this.

Not sure how we should handle windows which are minimized while the tool is starting up?
Any suggestions?